I doubt it… ReWire, Sample recording, LFO device, Hydra, Keytracking are all wishes done by various users not part of the League of Gentlemen if we both share the same definition of what it supposed to be.
Yes, I might have been exaggerating a bit. It was just rude dismission of ongoing discussion from BYTEs part.
How exactly was I dismissing conversation? I was simply responding to In-Fluence’s post. I’m not part of any league of gentlemen… I probably have less pull around here than you. I’m not even an alpha tester! I was just stating that there was an easier way of implementing what was initially asked for… that doesn’t mean it’s the most useful way… that doesn’t even mean I was rooting for it… I was just stating it would be easier… why so touchy?
Well I know what you said and according it you seem not care about points risen in discussion here. Of course it just can be coded, but there are some things that need to be addressed when thinking about how to achieve what we want. Because in some situations an extra device would be cumbersome if sheer amount of, say, asynced LFO modulation destinations are needed, opposed to in-device setting.
And I really think that since you are such a visible forum-character your voice is generally heard. However it might be, lets get back on the wagon, shall we?
I think that at some point major rethought about modulation routing needs to be done, since the more the options grow, the more unnecessary complexity it gathers with current device per task approach. This is why I see it more fruitful in long run to think about how we could as effectively as possible integrate options like this in where the modulation is sent or received.
I personally wouldn’t mind having modulation options for parameters like MIDI mappings where amount and range and sources and other options could be selected and set up, but this would be such a drastic change that I doubt anything like it would ever become reality. So the compromise would be to integrate at least delay and/or inertia settings in modulating devices, because for such a simple task a separate device would be just unnecessary extra link between source and destination.
Thoughts?
identifying a set of common parameters for every metadevice would be indeed a good way to make everything more clear.