View Single Post
Old 03-12-2012, 05:30 PM   #436
Human being with feelings
Banned's Avatar
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868

Originally Posted by BenK-msx View Post
not sure how you implemented the dynamic mapping you speak of banned,
As I said, it's just a proof-of-concept, and very rudimentary. For example, when using 16 plugin parameters for the control surface, and it sees that the plugin name is ReaEQ, it looks for a matching name in some list, and if it finds a match, retrieves a list of numbers, e.g.

1 4 7 10 2 5 8 11 3 6 9 12 13 14 15 16

... which will then remap the parameter numbers to line up the frequency controls as parameters 1, 2, 3 and 4; gain on 5, 6, 7 and 8; Q on 9, 10, 11 and 12. The downside of this simple approach is that it only works to swap numbers that are on the same 'page', and the same remapping will be active on all parameter 'pages', i.e. parameter numbers 17, 20, 23 and 26 will also change to line up as 17, 18, 19, 20. To work around this, I would need to dynamically change the number of parameters sent to/from the OSC control surface, to the total number of parameters, or at least to the highest parameter number (in the original order of the plugin) that I want to remap.

Storing such a simple number list per plugin as a text file, in a similar way as e.g. note name maps would be perfectly usable imho. And probably preferred by many users compared to putting xml files inside a .vst bundle (on Macs).

A benefit of the vstxml approach is that it could also work across different hosts, set once, work anywhere. Which is why this approach looked favorable, at least initially.

But in practice, vstxml does not seem ideal either. With some quick testing, I already crashed both REAPER and Ableton with such a modified .vst, so that may well be a decisive argument against using vstxml at all (if it works in REAPER but your plugins would be unusable with other hosts, things could easily become pretty messy). I should probably have thought of this before posting the FR as I did, but like BenK-msx says, however it's done!

[EDIT:] On further inspection, it seems that those crashes were not related to the .vst bundles including a custom vstxml file, but to the VSTmonitor.vst that came with the VST2.4 SDK; I had installed this along with the for dumping plugin parameter names to xml files. Sorry for any confusion.

Originally Posted by BenK-msx View Post
but personally i had thought of

[modifier]+clicking the parameters in reaper as a quick way to populate the 'device' page with parameters - ( how ever many params its set up for.)

for example last touched parameter works similarly so reaper can surely do it, this dynamic mapping could act in same way, acting as a buffer equal to the device's param number, so e.g the last four params you modifier+clicked with, would be mapped to page 1 param1,2,3,4

you could have 'assignments' saved per fx like we have with midi and default assignments like we do now, so you load the plug and its mapped how you like it or just do it on the fly as above.

+1 however its done!
I think you're combining a few clever ideas here, while I was starting with just one step at a time. Step one would be having some ability to reorder parameter numbers. Step two would be the ability to edit the order on the fly. Step three would be OSC support for changing them on the fly, for example following the approach you described using a 'last touched / learn' type of feature. Does that sound close enough to what you have in mind?
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ

Last edited by Banned; 03-12-2012 at 10:14 PM. Reason: added info on crashes during testing
Banned is offline   Reply With Quote