Using Ruby midi as O\I swithes

[kortezzzz]

Heya all,

I'm looking for a little Ruby solution with one midi in and one int out that can use midi as O\I switches. What I would like to do is octave based mapping. For example, each press on any c key (c1,c2,c3,c,4, etc) will send out "1" integer. If no c key is pressed the results would be "0" integer.

It can be done with green by using "note equal" and "midi mono" primitives, but the problem is that it's a real headache, since the "note equal" primitive can pass in only a single note, so mapping the whole keyboard octaves range means throwing 128 "midi mono" and "note equal" primitives into the schematic

In terms of speed and performance, maybe the green would be better and faster, even if I choose the 128 "midi mono" and "note equal" solution, but I'm not sure. In this case, Ruby's "elegance" can maybe win the speed and performance challenge and would be a lot more lightweight code and easy to develop. Any suggestions?

[Spogg]

I would like to see a Ruby-based MIDI “toolkit”. Individual basic modules that can take a MIDI input, apply a simple specified function, and output the MIDI result. These building blocks could then be used like prims, to piece together to make more complex stuff like ARPs and other sequencers, or even generative music devices.

I would also like to see a Ruby-equivalent version of the MIDI note prim where you specify a note number and length and it gives the MIDI out when triggered.

The problem I see is that Ruby seems to take its inputs only in green, unless you use frames. In green I experimentally found that above about 5 notes per second the timing becomes useless.

Maybe one or some of our resident Ruby wizards could have a think about this…


Cheers


Spogg

[tulamide]

Heya all,

I'm looking for a little Ruby solution with one midi in and one int out that can use midi as O\I switches. What I would like to do is octave based mapping. For example, each press on any c key (c1,c2,c3,c,4, etc) will send out "1" integer. If no c key is pressed the results would be "0" integer.

It can be done with green by using "note equal" and "midi mono" primitives, but the problem is that it's a real headache, since the "note equal" primitive can pass in only a single note, so mapping the whole keyboard octaves range means throwing 128 "midi mono" and "note equal" primitives into the schematic

In terms of speed and performance, maybe the green would be better and faster, even if I choose the 128 "midi mono" and "note equal" solution, but I'm not sure. In this case, Ruby's "elegance" can maybe win the speed and performance challenge and would be a lot more lightweight code and easy to develop. Any suggestions?

I don't know if I understood correctly. I attached a detector for the note C. It will spit out a 1 as long as at least 1 C in any octave is pressed, else 0. If that's not what you're looking for, please be more precise

[tulamide]

I would like to see a Ruby-based MIDI “toolkit”. Individual basic modules that can take a MIDI input, apply a simple specified function, and output the MIDI result. These building blocks could then be used like prims, to piece together to make more complex stuff like ARPs and other sequencers, or even generative music devices.

I would also like to see a Ruby-equivalent version of the MIDI note prim where you specify a note number and length and it gives the MIDI out when triggered.

The problem I see is that Ruby seems to take its inputs only in green, unless you use frames. In green I experimentally found that above about 5 notes per second the timing becomes useless.

Maybe one or some of our resident Ruby wizards could have a think about this…


Cheers


Spogg

I'm sorry to say that, but that's not practical. Ruby is a programming language. It can play out its advantages when gathering as many tasks as possible. Splitting it into tiny pieces makes it inefficient. Just think about possible issues with synchronization of some of those "prims", or value storing and sharing among the "prims".

And Ruby is not green. It has its own, way better, timing. Down to 10ms you will get a tick precisely on time. For comparison: At tempo 120 bpm that's 100 ppq. The sequencers in the late 80s had 96 ppq at most. And nobody had issues, instead the machine gun effect of all too precise hihats was a big issue back then. Plus, midi also isn't green. It also doesn't share the green timing (which is based on the Windows system timing and therefore unreliable)

[Spogg]

I'm sorry to say that, but that's not practical.
And Ruby is not green.

Fair enough! My suggestion was born of not really grasping the Ruby OOP yet I guess.

Regarding the green point: I was under the impression that, apart from Frames and View inputs, Ruby only accepted green-based inputs so that's where I was concerned about timing and not in the Ruby code execution itself.

Martin suggested (somewhere) that it would be nice to have stream-based MIDI prims and that seems to me, on the face of it, to be a good idea. DSP code, for example, could then be utilised to initiate MIDI events with potentially great accuracy since, as you say, MIDI isn't green even though there may be inherent limitations.

Cheers

Spogg

[tulamide]

Regarding the green point: I was under the impression that, apart from Frames and View inputs, Ruby only accepted green-based inputs so that's where I was concerned about timing and not in the Ruby code execution itself.

Martin suggested (somewhere) that it would be nice to have stream-based MIDI prims and that seems to me, on the face of it, to be a good idea. DSP code, for example, could then be utilised to initiate MIDI events with potentially great accuracy since, as you say, MIDI isn't green even though there may be inherent limitations.

As for Ruby: It accepts red midi inputs, which is totally out of the green limitations. Red is attached to the DAWs MIDI handling, so it will be as precise as the DAW (on incoming signals that is). Outgoing midi signals will be as precise as Ruby can be (see last post). But, there's more. People forget that Flowstone, although it pretends to work sample based, that is not quite true. It works buffer based, and the size of the buffer is defined (once again) by the DAWs selection of audio drivers. In case of ASIO I think I remember something like 13 ms on your system, so probably a buffer of around 256 samples. This window gives Flowstone the opportunity to precisely send midi within the buffer. However, midi is event driven, so it reacts on an incoming event, does the calculations and outputs the new event. If the calculations take too long for a buffer's length, it will be send on the next buffer. That is a limitation based on our developing ambition. The more we want to do with the midi event, the more likely it will be delayed.

The second point (stream-based) leaves the scope of midi. MIDI was developed long before DAWs and therefore digital audio sample streams existed. It was never intended to make it sample precise. It is event-driven and serial. It can't transmit several signals parallel. Instead, if you press a 4-note-chord on your controller, the 4 messages will be sent one after the other. This alone already introduces latency. Also it has its own timing called ppq and there's nothing we can do to change that. I agree that MIDI is a bit behind, but the solution can only be a new protocol, built from the ground-up to match the preciseness of audio streams. Up until then we're stuck with this dinosaur.

EDIT: I hope kortezzzz will notice that I already offered some help in a prior post^^

[kortezzzz]

If that's not what you're looking for, please be more precise

tula, thanks for the (too ) deep explanations and the example schematic

I don't understand all your comments, but do understand the main idea. Ruby is far better in terms of timing in FS (sequencers and etc), but not sure if its better when dealing with other tasks (like phisical keyboard spliting into 2 ranges or simple note streaming) unless you have the talent to avoid of building blocks which spogg mentioned and build the whole midi code in one single ruby block. Unfortunately, I don't have this talent and I'm sure that my schematic can be far more fast and optimized, but right now, I work with "patches" as default. No other chioce. But I still able to demonstrate idaes in that way, while I know that my developments in FS wouldn't become commercial anway, but will be used as a prototype only, for future C++ development. That's why I do believe spogg's idea to use a bank of building block is still effective. At the bottum line, most of FS fans are here for easiness and not for neto coding

About your exapmle: Its super fast+elegant and works great
But there is a small problem: It works only with "c" keys. If I would like to map other keys, and not only c, I can't actually use a direct multiplication of 12. In this case I would add another input to the ruby code which we can call "@ incoming_note" that would define with which note we are dealling. If it, for istance "d", the math then would be different.

[tulamide]

It works only with "c" keys. If I would like to map other keys, and not only c, I can't actually use a direct multiplication of 12. In this case I would add another input to the ruby code which we can call "@ incoming_note" that would define with which note we are dealling. If it, for istance "d", the math then would be different.

No, the math isn't different at all. There is no multiplication going on. My remark in the code was that any C is a multiple of 12. That's a difference. The actual math is Modulo and that doesn't change (if you look at the new example you'll see it). I extended the example to cover any note. If there is anything else, let me know!

[kortezzzz]

Fantastic, tulamide

This is exactly what needed. I'll try to learn the logic behind the code formulation. This little code is a must for sampler\sequencer\drum machine developers and will fit better my 9 preset managers schematic

[Spogg]

@tulamide

Many thanks for taking the time to explain this in detail.

Much appreciated

Spogg