Hi all, browsing through the headers and code, I found the following functions in csurf.h: extern int (*TrackFX_GetCount)(MediaTrack *tr); extern int (*TrackFX_GetNumParams)(MediaTrack *tr, int fx); extern double (*TrackFX_GetParam)(MediaTrack *tr, int fx, int param, double *minval, double *maxval); extern bool (*TrackFX_SetParam)(MediaTrack *tr, int fx, int param, double val); extern bool (*TrackFX_GetParamName)(MediaTrack *tr, int fx, int param, char *buf, int buflen); extern bool (*TrackFX_FormatParamValue)(MediaTrack *tr, int fx, int param, double val, char *buf, int buflen); extern bool (*TrackFX_GetFXName)(MediaTrack *tr, int fx, char *buf, int buflen); If I understand right, these methods should allow to control plugin parameters from the controller surface. Would this mean that the "inability" of Reaper to control plugins from the csurf, is not a flaw on the API, but a lack of implementation? Can anybody confirm this? Thanks!!

Digging in the plugin_functions.h, I found this: // category is <0 for receives, 0=sends, >0 for hardware outputs // sendidx is 0..n (NULL on any required parameter to stop) // parameter names: // "P_DESTTRACK" (read only, returns MediaTrack *, destination track, only applies for sends/recvs) // "P_SRCTRACK" (read only, returns MediaTrack *, source track, only applies for sends/recvs) // "B_MUTE" (returns bool *, read/write) // "B_PHASE" (returns bool *, read/write - true to flip phase) // "B_MONO" (returns bool *, read/write) // "D_VOL" (returns double *, read/write - 1.0 = +0dB etc) // "D_PAN" (returns double *, read/write - -1..+1) // "D_PANLAW" (returns double *,read/write - 1.0=+0.0db, 0.5=-6dB, -1.0 = projdef etc) // "I_SENDMODE" (returns int *, read/write - 0=post-fader, 1=pre-fx, 2=post-fx(depr), 3=post-fx) // "I_SRCCHAN" (returns int *, read/write - index,&1024=mono, -1 for none) // "I_DSTCHAN" (returns int *, read/write - index, &1024=mono, otherwise stereo pair, hwout:&512=rearoute) // "I_MIDIFLAGS" (returns int *, read/write - low 5 bits=source channel 0=all, 1-16, next 5 bits=dest channel, 0=orig, 1-16=chan) // set setNewValue to non-NULL to set the value REAPER_PLUGIN_DECLARE_APIFUNCS void *(*GetSetTrackSendInfo)(MediaTrack *tr, int category, int sendidx, const char *parmname, void *setNewValue); which, if I understand right, allows to manage track sends. The csurf.h doesn't have any mention to track sends, but it doesn't look too hard to implement it in a custom function.. Any thoughts about this? Cheers!

Hi pollux That will be a great improve for all of us who use control surfaces. Are you going to make it available for MCU? Right now I use a M-Audio Projectmix I/O based on that protocol and back on my Nuendo days I could get to plug-ins parameters pushing "plug-in" button on the control surface. Thanks for the big work... really appreciated! I hope you can make it happen

btw, I'm available for testing it whenever you get it done :D

Thanks a lot klinke, that's really kind... we all need that kind of features on our Control Surfaces! Could I ask one big favor? is it possible to make an MCU based Control Surface change its mode to MIDI controller and backwards juts by pressing the "midi" button on it? I think that maybe you can look at it when coding because it would be really useful to push that button and change its state, this way we could automate envelopes when it's in MIDI Control state and then come back pushing it again to the Control Surface state.

please generalize the concept a bit more, if possible 

Hey, I will join the discussion and add what I can, I am somewhat new to reaper, however, I have made a preset for the BCR2000 that will emulate the mcu. This plugin extends the functions of the emulation as well. I also created genmce and hope that the plugin will work for people who don't have a bcr2000 nor a mcu. I have not tested it yet. perhaps today. I need to read thru the discussion again to try to provide any comments. This discussion is very detailed and sounds very promising. Getting sends control as well as plugin control would be awesome.

Great ideas! Please don't forget the mcu extender..

I just closed the browser with an longer reply :-( So here only a summary. First, thank Goeff for your thought, they wheren't to formal for me. In overall the are matching with the ideas i have (which are got quite conrete in the meantime). I see difference depending the Send Mode, i don't plan to mix them with the Track-Volumes, the complete Fader/VPOT/Mute/Solo/Fader bank section will be used for the Sends/Receives (like suggested from pollux). But if you only want to change a single send-level, you can change the send-level while you are pressing the send-button and after releasing the send-button you will be back in the Mix mode again. So no option is necessery to determine the usage of the Fader Bank buttons in the Send Mode. Depending the plugins i still want to go the config-file way, but i like your idea of selecting the parameters to control via the VPOTs. But how and where to you want to store the changes the user had made? Best, Klinke

Cool, I really like your idea of a "Temporary" or "Momentary" Send mode. As far as saving the user changes, I think we may need a small "wrapper" (Decorator Pattern if you're into that stuff) that adds just enough MCU state / paramater info to each FX slot at runtime to achieve this, so that when we go somewhere else and return we aren't surprised. I don't know how hard this will be to implement -- as I said I was concentrating on the dreaming / analysis part in my post -- we will of course face the real world constraints of the VST <=> Reaper boundary interaction. We could then either: Not persist this info to disk -- the next time the app was loaded we would start over as far as navigation within each VST was concerned Use your config file approach to store this info -- so for instance if we were adjusting Q on an EQ when we last saved / quit we would come back to that state. I think either way is cool from my perspective.