Neat, I happpened to rediscover and sort my childhood lego collection two weeks ago, and had good success for the "no so common parts" with the brickowl camera search (I don't know what kind of engine is behind)
I spent some time using the GoVCL bindings of Lazarus LCL, and made some small app with it: https://code.ivysaur.me/yvbolt
It does work, but I had hoped for more, it is simply too far behind in many ways and is stuck on GTK2 (so no high DPI support). The LCL itself does support GTK3 and Qt5 (and nothing newer), but recompiling GoVCL to use them broke quite badly.
I also manually upgraded yesterday (bad luck, just a few hours after the update) and just now reverted to the previous kernel. Not sure this was the right thing to do but didn't want to take any chances
Nice, I did a similar hack some time ago: pack your favorites functions/aliases in b64, unpack and do some mkfifo on the server, write that fifo path to ENV, and call "exec bash --posix". zsh and ksh also work, as they also have some options relying on ENV.
Why? 64 bit chips are dirt cheap these days, if anything it's surprising they went for 32 bit instead of just going for 64 to buy the protocol one or more decades of "no one's going to run into the limitations of that".
Don't design it for what humans expect, design it for what the machines that need to talk to each other operate on. In that sense, 32 bits is the bare minimum you want in a new spec.
Because MIDI has very low bandwidth. People in complex environments doing complex things saturate it already. The new version may somehow allow higher bandwidth but it wants backward compatibility as well. We'll see, I'm sure this version will be better and I hope it becomes more popular again.
because the intent of a CC is to emulate a knob on a synth .
A synth knob turns a little less than 360 degrees. While 7 bits doesn't give quite enough resolution to have one degree per code, 32 bits would give 11 million codes per degree. Even a thousand codes per degree would suffice... but 11 million?
There would also be no analog to digital converter that could measure much more than 24 bits with any accuracy whatsoever.
And if you were to use your proposal of "just going to 64" it would multiply the space between the existing 11 million values between every degree on a knob by 4 billion. That would have 44 trillion variations of knob control. No one can sense that. if the knob was used to modulate e.g. LFO speed, it could send changes that wouldn't even be heard for millions of years.
> because the intent of a CC is to emulate a knob on a synth .
The intent of CC is to facilitate control changes. Higher range means greater flexibility in what exactly this means. Just off the top of my head I can think of at least one realistic application where 360000 discrete steps simply wouldn't suffice but a higher range control protocol would be useful: precision audio seeking, because recorded audio used in music is often longer than 360000 samples.
Then you're not being creative enough. Digital turntables are extremely precise. I once hooked up my ns7 (1) to an old windows laptop, spun the turntable, and crashed the computer. I think that highly precise applications like this could find valid uses for 32 bit control
Interesting, you're right for this type of things "MIDI" controllers usually had to resort to HID (e.g. platters on most DJ controllers), I'm curious to see how people will use MIDI 2
With this spec, my LFO can be on a separate device and spit MIDI to modulate sample-accurate playback of an entire season of a TV show (assuming that it can be loaded into memory) recorded at 96000k.
but imho, given they already downgraded the behavior in 4.0, this is really looking like a security hole that might be closed in a next Android release.
