arduino_midi_library VS GoJS, a JavaScript Library for HTML Diagrams

That makes me wonder how often one runs across a synth that doesn't support running status. I'm working on a MIDI controller myself, and that's a thing I probably ought to enable if I want the lowest latency.

It seems the standard MIDI libraries that Arduino uses don't enable it by default, but it's a configuration option you can turn on, along with a note not to try to use it with USB[1].

[1] https://github.com/FortySevenEffects/arduino_midi_library/bl...

take a look here

The Arduino MIDI Library [1]. Back in 2009, I learned C++ to build it and control my guitar effects pedals with custom electronics as part of my engineering degree.

[1] https://github.com/FortySevenEffects/arduino_midi_library

Your project can be broken up into a number of subprojects. For keyscanning you don't need additional hardware, just the pins from the ribbon cables going to the arduino's digital pins and ground. Since the keys are just switches (two per key, the time difference between the two switches closing giving the source of velocity), you could start with some examples from the Arduino MIDI library (https://github.com/FortySevenEffects/arduino_midi_library). To test MIDI sending you don't even need to start from the keybed just yet, and if you do, you can start with a single key. Once you've got that part figured out end to end (key press/release generates note on/off events) you can work on iterating through the matrix, CC controls etc. MIDI out can be done in different ways. With a 5 pin DIN plug you'd just need two 220 ohm resistors.

On an Arduino compatible platform the configuration of the baud rate at the bare metal layer is taken care of by the library when you call its begin() method. Looking at the example code included with the library it appears that there are no timer interrupts or anything like that required of you in order to use it. Another thing that jumps out is that the call to read() returns a non-zero value if anything has been received that you should use to predicate whether any further attention needs to be spent on it by your code. You may know this but it wasn't apparent from the loop() { MIDI.read\`() }` example that you gave above.

As i have started to combine this with Midi Implementation from FourtySevenEffects lib, i only have done a quick test with two/three strips and did discover follwing issue(s):

Using a library for the midi shield you can register two functions as callbacks. One callback for NoteOn(...) messages and one for NoteOff(...) messages. But thre is much more. In the end the source of truth should always be the docs for the library itself.

Click the link to github (second link in the article) and there's all the source code: https://github.com/FortySevenEffects/arduino_midi_library

Here’s a library that might work.

If you click on their username, it takes you to their profile.

https://news.ycombinator.com/user?id=simonsarris

which says:

I make GoJS, a powerful canvas-based diagramming library:

http://gojs.net/

Have spent six figures yearly on ads, mostly for reach for the developer-focused diagram library GoJS (https://gojs.net)

> Each experiment will need ~$500 and 2 weeks

I would add a zero if you want serious data. I would also double the timescale. $5,000 over 4 weeks

I second the uselessness of Google Display, it might look like conversions numbers are good but they are 100% too good to be true. As soon as you look into them you find the sources are things like "ad from HappyFunBabyTime Android app". You have to ruthlessly prune daily for months to get anything real, and even then I'm skeptical of value. For a developer tool with very strict conversion metrics!

But I disagree on Google Search:

> Good for conversion, bad for awareness.

Before we were popular it was excellent for awareness. Post popularity its much more arguable.

Creating the Halogen components would be simple enough if one takes inspiration from gojs-react. The issue is that there are no PureScript bindings for the GoJS types themselves, but GoJS does provide .ts.d declarations, which means I could use purescript-read-dts, but that library's maturity/usability seems somewhat ambiguous, according to an author's post from 3 years ago.

used goJS in one project and konva in another

I built GoJS, which is one of the most popular commercial JS diagramming libraries: https://gojs.net

I built carefulwords, a very fast thesaurus and quote site for inspiration, used by... tens of people a day. Eg: https://carefulwords.com/gift https://carefulwords.com/solitude

I mostly made it for myself, me and my wife use it all the time. I am slowly editing down the thesaurus to managable size.

I built a 12x16 "Goose Palace" barn out of local pine timbers, which taught me timber framing, and taught my tiny baby who turned 2 years old while doing it that this is just the kind of thing that people normally do, build barns in their driveway. Some context: https://simonsarris.substack.com/p/the-goose-palace

Some photos of building it with the baby: https://twitter.com/simonsarris/status/1584169368203956225

I designed my house, and have been writing extensively about that. Maybe this is the most impactful, since photos of it are all over Pinterest and other sites, now. The first post on that: https://simonsarris.substack.com/p/designing-a-new-old-home-...

I am not sure what is most impactful. Maybe ultimately it is building my family.

I made a pull request for GoJS (https://gojs.net)

I have been building this canvas-based graphing library since 2011, and it contains a good number of features around customization and interactivity that are not found in other libraries. It is commercial for non-academic use however.

in one project we use konva, in another we used gojs. Any of them or some other library needs some training and introduce own limitations but it still way way way better than handing all the coordinates, calculations, routing etc on your own.

I am really surprised by this guy's opinion. I make GoJS (https://gojs.net/), a diagramming library written in TypeScript. The project began in 2011 and we converted it to TS in 2018. It's been a huge plus. The sole downside was the initial time it took during conversion, but even in doing so we caught bugs with incorrect input types, documentation mistakes, etc.

On our end, it enforces type safety better than the Google Closure Compiler. There has scarcely been a problem with type complexity that was not ultimately our fault. Just a couple minor things that TS amended later. For that matter the TS experience has only gotten better, generally.

On our users end, we can now give them a .d.ts file that's much richer and easier for us to produce to aid their autocompletion. And we can use that .d.ts file to ensure that all the methods we intended to expose/minify are getting exposed. The advantages with the .d.ts and documentation make it feel almost essential to me for library developers to consider TS.

TypeScript has only made debugging easier, much easier since it catches errors at time of typing unlike the closure compiler. The sole exception is that debugging is a bit slower since I have to transpile instead of just refreshing the browser. But I have tsc set to compile a relatively unminified version of the JS. But if the slowness gets to me, I can just edit the JS output until I solve the issue, and then carry those edits over to the TS. This has never felt like a problem, though maybe his library is significantly more complicated.

Feel free to ask me anything if you have questions about library design + TS.

GoJS might work for you: https://gojs.net

Although the focus of the library is interactivity and not setting up sequences of animation, but that is possible too.

My livelihood has been primarily building a Canvas diagramming library since 2010 (https://gojs.net), if anyone has any questions about 2D Canvas use in the real-world I'd be happy to answer them.

roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). I'll have to do some performance comparisons, since that's the operative thing for my use case (and any library author).

text modifiers are very welcome. It's crazy how annoying measuring still is, especially if you want thinks to look perfectly consistent across browsers. Though the chrome dominance is making things easier in one way, I guess.

context.reset is kinda funny. Most high-performance canvas apps will never want to use it. For that matter you want to set all properties as little as possible, especially setting things like context.font, which are slow even if you're setting it to the same value. (Or it was, I haven't tested that in several years).

I'm sure most users know this by now, but generally for performance the fewer calls you make to the canvas and the context, the beter. This is even true of transforms: It's faster to make your own Matrix class, do all your own matrix translation, rotation, multiplication, etc, and then make a single call to `context.setTransform`, than it is to call the other context methods.