Ruby question - Modulo based midi switch

[kortezzzz]

Hi,

I need help with a simple Ruby midi module with 2 inputs (midi and int) and 1 output (int) that outputs 0 or 1 based on modulo parameter. What the module does is very simple: it gets the played midi note number when the key is on, then divides it with 12, finds the modulo and outputs 1 whenever the modulo is equal to the input. If the key is gone off or the modulo is not equals to the input value, the module outputs 0 .

Example:

1) The int input is set to 2
2) I play the note 50 with the midi keyboard. The module divides 50 in 12 -> 50/12 = 2 with modulo 2 (48 +2)
3) The module outputs 1 when the key is on (since the int input is equal to the modulo parameter)
4) The output becomes 0 when I release the midi note
5) I play note 52 -> the output remains 0 since the modulo and the int input are not equal

Thanks

[trogluddite]

What you're asking for is very similar to the "Chord Maker" that I put together for Spogg's HarpVerb (LINK) - that already has all the note-on/note-off logic that's needed, and it also uses mod-12 maths to "wrap around" the octaves. I'll have a go at removing the bits you don't need and get back to you.

[trogluddite]

I think the following schematic will do what you want. To save repeating the MIDI note buffering part of the code, I've split the solution into two modules - the first one keeps a list of what MIDI notes are currently playing, and then you can plug as many 'note detector' modules as you want into that.

wrapped_note_detector.fsm

(1.35 KiB) Downloaded 783 times

The "octave wrapping" of the detectors can be turned on and off from a property, so you can use the same module to detect an absolute note as well. The connectors and links for the list of notes would work equally well if they were Green Integer Arrays - but Green <-> Ruby conversions for Arrays are quite costly, so using 'Ruby Value' links makes things a little bit more efficient.

[kortezzzz]

Thank you so much, Trog
You are right. I needed it for my arranger organ's chord system and I actually have another version of this module which have been made by tulamide some while a go. All those modules are wonderful and usually do a great job , but... unfortunately in my schematic they don't work so well in one finger mode and the switching goes a little slow and misses the real time performance speed that I needed, so my main idea this morning was to make a modulus driven ruby module for each note of any possible octave (12 notes in total) which will output values from 0 to 11, no matter which octave you play. For instance, if you play key 50 or key 62, it will still output the value 2 and keep the right chord playing.

Later today, after posting on the forum, I decided to abandon Ruby for this task and go to the green Midi mono module as a solution and used the modulos primitive to do exactly what I needed and it finally worked. I have no idea if its better than Ruby in terms of CPU and Ram usage, but its FAR MORE FAST AND ACCURATE in when real time performance is needed although the green build is a clumsy hypo ...

Anyway, thank you for your hard work and your attention to details. You are a legend

[trogluddite]

You're welcome, and thanks for your kind compliments - just what I needed to take my mind off the rotten hangover I've had all day!

I have no idea if its better than Ruby in terms of CPU and Ram usage, but its FAR MORE FAST AND ACCURATE in when real time performance is needed

If mono is all that you need, your 'Green' solution is likely to be better in every respect. Aside from avoiding the timing issues that you mentioned, it will almost certainly use less RAM (no source code to store, and 'green' values are much more compact than most Ruby objects), will load faster (no source code to parse), and, so long as triggers are well managed and its not too convoluted, will use less CPU (no queuing of 'events' or copying/conversions of values, no method names to look up, etc.)

Much as I love all the shiny toys that Ruby gives us access to, I don't see any point in adding those extra overheads unless you really need the extra Ruby features or unless Ruby makes it much easier to build something.

[kortezzzz]

Well I see that my thoughts were true. In future builds I'll try avoid Ruby as much as I can and keep it as "spacial missions tool". By the way, Ruby is awesome when you need something static and complex which has no speed factor. For instance, radio buttons which I use a lot. The one that you made few years a go with the string array input is a master work

[tulamide]

It somehow feels strange. I remember having done some modulo calculations to always spit out the correct note through an octave, but I can't remember if it was for you. However, the one I made isn't slow at all and has no timing issues, so it might have been for somebody else. I've also done arp/sequencer works for Adam's Viper, also perfectly on time. So maybe I misunderstood, but because you mentioned me, I want to make sure, my reputation doesn't suffer from rather general statements.

[kortezzzz]

Tulamide, it was for me. Here is the original post

viewtopic.php?f=2&t=8773

And guess what?... after visiting the post again, I see that in your first comment there you posted exactly what I needed I just forgot about it since it was 2 years a go
Anyway, I downloaded it and now trying it compared to the green. There is nothing wrong with your reputation
Its just that arranger organs that work with midi styles should switch style chords extremely fast and when you jump to another chord in high BPMs it sometimes has a slight delay which is not occurs with green midi mono. I suspect that the reason is that all notes are generated from the same module (with 12 outputs). That's why I tried to make a separation and use a separated module for each note.

[trogluddite]

because you mentioned me, I want to make sure, my reputation doesn't suffer from rather general statements.

The only general statement which mentioned you was...

All those modules are wonderful and usually do a great job

It's just as well that your contributions are always so good - I'm not sure I want to know how you'd react to a bad review! IMHO, reputations are just like cats - easier to attract if you act indifferently to them, and elusive when chased! If you keep posting the quality contributions that you always do, your reputation will do just fine.

The specific (not general!) situation where the modules didn't seem to work so well does brings up an important point, though. No matter how much effort we put into the modules that we share, we don't have any control over what environment people use them in - and downloaders should always bear this in mind. This is particularly true where timing is critical, because the timing of a schematic can only be as good as the "weakest link" which has the worst jitter (almost always the green trigger problems that we've always had, somewhere along the line.) The schematic that a module is dropped into can easily have elements which confound its advantages, or the module might not fit the context as well as originally thought (like the modules I posted earlier, which work fine for poly, but don't really suit kortezzzz's mono-only requirement.)

It's also worth remembering, whether we're reading or writing, that English phrases like "it doesn't work" can be very ambiguous, even to those of us who are native English speakers - anything from "it's terminally broken, you idiot!" through to "D'oh, that's not the screwdriver I meant to use!".

[kortezzzz]

Every word, trog!

Contributors can write a bright code but in the end, they test it in a sterile schematic before uploading. Only the downloader can explore it's odd sides in different environments. Tula is a top contributor and I appreciate his cunning solutions and moreover, I'm even kinda looking for his comments in new posts. I don't think that he can ever do something that will harm his reputation