From the original SynthMaker forum (2004–2014), with its members’ names and dates.
trogluddite ·
Hi All,
I noticed when making my MIDI Manipulator that the stock "Note to Int" primitive does not correctly parse note names for the lowest octave, where the octave number goes negative (e.g. D#-1) - they get treated as if the octave were positive, and end up two octaves higher than they should be.
Of course, that's way below the range of most people's MIDI keyboards - but I like to use those 'sub-bass' note numbers sometimes on my MIDI controller, as they are easy to filter out for use as keyswiches.
Also the note names are just arbitrary labels - some MIDI manufacturers label 'Middle C' as C4, others as 'C3' or even 'C5', and Mr.Infuzion seems fond of 'Middle C' = 'C0' (which to me seems eminently sensible).
Here's a little module that corrects the bug, and also has a property so that you can decide for yourself in which nominal octave 'Middle C' lives (set to 4 to match the stock 'Note to Int' primitive)....
Acrobat ·
Nice! Thank you! A parse work! 😀 A.
oddson ·
Shouldn't a trigger from the Octave property update the results.
(Note sure why the sample and hold on that part either.)
trogluddite ·
oddson wrote: Shouldn't a trigger from the Octave property update the results.
(Note sure why the sample and hold on that part either.)
In a nutshell, trigger reduction, and preventing the passing on of spurious values...
The parser's 'after' trigger is always last in sequence, no matter how many 'or' or 'optional' parse sections there are. Each individual 'extractor' (i.e. action/integer/float etc.) generates a trigger when only its own little section has found something - even if the rest of the parse is incomplete. For example, if you typed: "C,#,<oops got it wrong>,delete,delete,D,#'" the string section would generate 5 new values (and triggers) - all spurious data using the previous 'octave' entry.
Even if you used an edit box with the 'only on completion' set to true (to avoid parsing half-typed entries), you'd still get one extra trigger from the string section - and possibly many more with very complex parsing set-ups.
in this case, you are quite right - if an integer is parsed, then the whole routine is complete, and that would do just as well - but in parsers with many 'or' or 'optional' blocks, it's not always clear which would be the final section, so using the 'after' trigger/'valid' bool combo saves any head scratching - a sure fire way to know that each typed entry will create only one trigger on completion.
Tying the S&H to the 'valid' boolean also prevents invalid entries from being passed on - you could even re-direct 'not valid' triggers to an error handler (e.g. "Try Again" message box, etc.).
trogluddite ·
And for completeness, now recognises flats ('b') too...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker