From the original SynthMaker forum (2004–2014), with its members’ names and dates.
trogluddite ·
Here's my latest work in progress.
It's inspired by the one bit of Cubase that I still miss after moving over to Reaper - the logical MIDI editor.
It lets you apply complex transformations to incoming MIDI messages based on multiple filter conditions and messing with the MIDI data bytes. Including...
-Full re-mapping and re-channeling of all controllers and program changes.
-Four blocks of logical filtering and warping.
-Internal variables that can be set and read by MIDI messages (think mod.wheel scales note velocities etc.)
-Basic maths and range scaling functions for parameters.
-Mix and match decimal, hex and note names for parameter entry.
-Switch setups and turn transformations on and off via MIDI.
-Cut, copy, paste of banks, presets, filter blocks or mappings between presets and instances.
-'mini' version with basic GUI - paste stuff from the big'un into here for a nice CPU lite, small screenspace setup.
And here's a rough draft of the user manual, so you can understand the syntax for the filters and 'warping' boxes (the built in presets should help with this too).
Still very much a Beta - I'm using some of my de-bugging to inspire a few new trigger tutorials, as fast MIDI data and live MIDI monitor screens require some hefty trigger reduction! - with the full GUI on screen you may get the odd crackle due to the trigger flurries, but (for me) they go away when the GUI is closed or if I use the 'mini' version. That's partly why the maths parsing is a little esoteric - to avoid too much stuff in the main MIDI data path.
Lets hope SM gets Ruby soon - this is the kind of stuff it would be perfect for.
Have to give a big shout to DWB - his recent parser examples opened the door to the text handling needed for the maths 'formula' entry boxes.
attic ·
Wow this is useful and a truly deep midi app. Thank you for this. I am reading the manual right now while trying different things and I am wondering if this will allow me to remap the input from my keyboard backwards. Can I remap the entire keyboard range to inverse so lets say middle c stays exact to its normal position but the left of the keyboard would play high notes and the right low?
Great work Trog, the level of professionalism in Synthmaker design from you is astounding.
trogluddite ·
Glad you like it! 😀
attic wrote: Can I remap the entire keyboard range to inverse
He he, great minds think alike, as they say - There's a preset "Topsy Turvy" that does just that (to the pitch bender also) - but it only takes effect when the sustain pedal is pressed (easily removed).
A word of warning though - this is one area where improvement is needed - if you select any of the pitch/note programs (especially the 'switchable' ones) while notes are held, the notes ons and offs can end up with mismatched pitches, and some notes can get 'stuck'.
For my 'stream MIDI' experiments I have a lovely buffering system worked out, but the algorithm is just way to greedy for triggers to work in the 'green' domain.
DigitalWhiteByte ·
DWB say Thanks 😀
attic ·
There's a preset "Topsy Turvy" that does just that (to the pitch bender also) - but it only takes effect when the sustain pedal is pressed (easily removed).
Ah Ha .. Thank you. Very useful. Now for some experimenting with this beast. Great job! Ill let you know where my experiments take me. 🙂
kirkagur ·
Hi ,trogluddite
awesome work!
😉
can I hire you to write documentions?
oddson ·
Epic build Trog... I'm wondering what was behind the decision to decentralize the parsing to so many different modules and what the Bus data structure gives you?
To be honest I've only given it a cursory glance so I may be missing the 'obvious' but it is rather complex.
RunBeerRun2 ·
Wow is what I first thought, haven't really looked into how you did what interests me.
I use a Yamaha ez-ag midi guitar which is terrible, I might want to check this out for that.
trogluddite ·
Thank you all, it's great to get such a positive reaction to my work over the holidays! 😍
kirkagur wrote: can I hire you to write documentions?
Very flattering, thankyou - but in between my full time job (partly writing tech.docs.) and my personal SM/music projects, I struggle to find the time/remember to have a social life/eat/shop/dress myself/poo etc.!
(it's sad how little of an exaggeration that is!). 😊
oddson wrote: what was behind the decision to decentralize the parsing to so many different modules
Not sure 'decision' is the right word - more a matter of project creep! 😉
Once I realised how big it was getting, I did wonder whether a centralised string array might be better - however, the VST preset string limit of 255 (IIRC) characters could be a problem, and possibly the 'macro-parsing' into the individual entries might slow preset changes.
oddson wrote: what the Bus data structure gives you?
Mainly I wanted to avoid unnecessary MIDI event -> MIDI split translations - early versions were incredibly CPU greedy, and that was one of my prime suspects. I'm less sure of that now; maybe using MIDI links to move data between sections would work just as well. One slight advantage is not having to worry about processing/blocking the triggers that come from the MIDI splitter integer outputs - mostly I've tried to use the discrete 'trigger' path to drive everything, with the actual data requested only when needed by the 'backwards triggers' created when one of the warps is triggered.
Another difference with busses is that once they are in place, they seem to act as if they were hard-wired links, as opposed to, say, multiplexers and selectors that have a 'decision' to make whenever data passes through.
Judging from my early prototypes, the routing within the filter sections works more efficiently this way (there are many different combinations of possible paths there) - once you have decided on the position of the brackets, SM seems to treat the buses as if the schematic were built with that configuration - I guess the downside will be more work for SM to do when you change the routing (parsing bus names and matching the end-points), but keeping as little processing in the MIDI data path was definitely the priority here!
Dozius ·
I've always wanted to do something like this, but lacked the motivation. Great work!
sunsynth ·
Awesome work - again Luddite 😍
Thanks 4 the easy enlightening MUX'er solution...
Damn - why didn't i had this 'simple' idea long ago 😊
Report: Wow - i could reduce some of my EXE's around 80% CPU use 😀
As usual - keep on doing (use my EGGY 2 remind u eating/drinking etc. and the opposite part 😉
trogluddite ·
sunsynth wrote: use my EGGY 2 remind u eating/drinking etc. and the opposite part
He he. Yes, good idea - but I fear it would be like the morning before I go to work - beep, beep --> "Rude words!!" + press 'snooze' button --> beep, beep --> "Even ruder words!!" + press 'snooze' button --> beep,beep - ......
sunsynth wrote: Report: Wow - i could reduce some of my EXE's around 80% CPU use
That's great to hear - mostly I was just following my instincts and not very 'scientific' thinking.
It seemed that the CPU meter (Task manager etc.) was not so useful for this project - I think also for many 'fluorescent green' projects! The 'trigger flurry blips' all happen very fast, and CPU meters are very slow and don't see the peaks. So I put a small ASIO buffer size in the host, and listen for 'crackles' - maybe in some way this is a better test when there is no stream DSP.
Dozius wrote: I've always wanted to do something like this, but lacked the motivation. Great work!
Thankyou. 🙂
I Know what you mean about motivation - 'utility' modules are no match for a good 'crazy sound' project! If only my MIDI controllers could have all the good features in one unit (or OSC!), I would never have made it - but using up sequencer tracks just to get the right data in the right place at the right time was really starting to get silly. Very much a case of necessity being the mother of invention!
trogluddite ·
Version 2 is now in the top post.
Just some small improvements to the 'green box' parsers...
- The abbreviated Data1 and Data2 variables are now 'DT1' and 'DT2' to avoid confusion with notes D1 and D2.
- It's now OK to use single digit hex numbers (e.g. $A), no need for 'zero padding'.
- Note names can now use flats ('b') as well as sharps ('#').
The user guide has also been updated with these improvements. Presets made with version one will mostly still function OK - unless they used the old 'D1' and 'D2' variables (they will now parse as notes - just edit the text to use the new 'DT' versions to correct this). This applies to the 'mini' version too, as it uses the same underlying parsing for presets, so be sure to upgrade both 'mini' and 'maxi' versions.
DigitalWhiteByte ·
Hi trogluddite,
would you explain to me why you use, the primitive LOOP, as New ID Trigger?
trogluddite ·
First - a qualifier.
I put those in because of some problems quite early on - TBH, I haven't tried removing them in the newer version, but I imagine the problem is still the same.
Each trigger has it's own identity (some sort of hidden tag). Most primitives will read this tag in order to know whether each trigger has been processed or not. How they deal with that seems rather unpredictable - I'm still trying to work out the exact rules for inclusion in the trigger tutorials.
For example, with most simple maths prim's, you can connect up big networks of them, where the initial input trigger has many routes to the (same) output, but there is still only a single output trigger...
Other times, usually with more complex prim's, the multiple paths will duplicate the triggers...
For MagiMIDI, the 'Add' mode needs the 'extra' trigger, so that it can generate an additional MIDI message - but that wasn't happening; SM's trigger system was stubbornly treating it as 'already processed'.
The zero-iteration counter is a trick that Malc showed me - it is guaranteed to produce an output trigger with a whole new identity; which will always force a new round of calculations. (possibly there are other ways, but he assures me that the 'zero-count' is likely to have the lowest processing cost).
They say that dogs are man's best friend - but an SM'ers best friend is the trigger counter. It should have a smily face, and big round wet eyes! 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker