It works like this in Reaper. Setup in the prefs. OSC Device, we'll call it Bob.
Bob sends strings like "/track/2/volume 0.3".
Reaper interprets these strings with the help of its OSC config, which tells it what to expect and what internal functions to mess with as a result.
The OSC config is also the place where Reaper it told what to send back to Bob.
Bob will then display whatever Reaper sends in its own way. Lemur for example has a multitude of meters, string displays and pulsing buttons to name a few to show you what Reaper sent.
There's a bunch of clever stuff so you only need to setup a few things, such a patterns. I'd have to read up on it again, because I just use my Lemur template in everyday mixing without thinking about it any longer.
I mean, do you need me to connect the desk to a MIDI capture utility, then literally move every single fader, knob, switch etc on the desk and log what message it puts out? Or is there a "dump" the desk can do of this, for example?
Nothing fancy, just test if all controls generate midi message(s), that's all, we can sort out the rest later.
Quote:
Originally Posted by andyp24
Airon, I know the X32 is OSC capable. If only I knew what that actually really means (short of being another communication protocol, obv). There is a website by Patrick Gilles-Maillot which has utilities for X32 <-> Reaper with OSC, but 1) the Mac utility is command line only, which puts me off a bit (I'm not used to messing around with the terminal) and 2) as far as I understand, for it to work, you have to configure the utility in advance with how many tracks are in the Reaper project. That makes it sound like a pain if you want to use the Controller as a project is in progress, rather than just as a final mix tool. I may have completely misunderstood this, of course, but the site seems lacking in a simple set up guide.
Yeah, I had a look at that today, looks very complex at first glance...
With the new requirement that we respect a naming convention, as discussed previously., we can now break things down more logically, here's the latest thinking:
///////////////////////////////////
CSI.ini -- main ini file
right I get it now, it was the threshold, character part that was throwing me, due to having no experience of the console1,
Looks great, even i understand lol,
Thanks for clearing that up for me.
Geoff, are the FX maps going to be, separate individual fx files, one big fx file, or part of the main file? Or have you got that far lol.
Sounds like it's going to be great.
Geoff, are the FX maps going to be, separate individual fx files, one big fx file, or part of the main file? Or have you got that far lol.
Sounds like it's going to be great.
Now that we are using the naming convention, I think individual FX files make sense.
We will also need different FX maps for the same FX for different control surfaces -- e.g. ReaComp for C4 vs ReaComp for Console 1, directory structures will come into play to keep things sane.
The new thinking is to allow map file references from within map files to arbitrary depth, in order to make the process of building custom Logical Surface maps as easy as possible.
Now that we are using the naming convention, I think individual FX files make sense.
+1.
Quote:
Originally Posted by Geoff Waddington
We might also need different FX maps for the same FX for different control surfaces
Obviously.
Quote:
Originally Posted by Geoff Waddington
The new thinking is to allow map file references from within map files to arbitrary depth, in order to make the process of building custom Logical Surface maps as easy as possible.
I've mapped what I can of the X32, and disappointingly for me, only one of the rotary controls (assignable pan knob) sends any MIDI data in any mode that I can discover. Neither, for some strange reason, do the Solo buttons (except some of them in Remote mode).
So, it's not going to be quite as flexible as I hoped, although there are still quite a few faders and buttons (latching and non-latching) which do deliver data, depending on the mode the desk is in.
Hopefully at least the Faders and switches would be useful for me if your project can build a map for it. I might have to look into another general purpose knobs and buttons MIDI controller for FX use as well (ideas please?).
Hope this helps.
Best,
Andy
Briefly (let me know when/if you want a full list of what sends what):
The one physical Assignable Pan Knob sends 00-7F for up to 64 different channels (according to the Bank and Channel Selects on the desk)
CHANNEL SECTION
8 physical Mute Buttons send 00 or 7F (latching) for up to 64 different channels (according to the Bank Select on the desk)
8 physical Channel Faders send 00-7F (nothing sent when Touched or Released, only CC when moved) for up to 64 channels (according to the Bank Select on the desk)
BUSS SECTION (Normal desk mode)
8 physical Mute Buttons send 00 or 7F (latching) for up to 31 different channels (according to the Bank Select on the desk)
8 physical Channel Faders send 00-7F (nothing sent when Touched or Released, only CC when moved) for up to 31 channels (according to the Bank Select on the desk)
One physical Main Fader sends 00-7F (nothing sent when Touched or Released, only CC when moved) for one channel
BUSS SECTION (DAW Remote mode)
8 physical Select switches send 00 or 7F (non-latching) for 8 channels - Note On/Off
8 physical Solo switches send 00 or 7F (non-latching) for 8 channels - Note On/Off
8 ohysical Mute switches send 00 or 7F (non-latching) for 20 channels - Note On/Off (according to the Bank Select on the desk)
MISC BUTTONS
6 physical Mute Group buttons send 00 or 7F (latching) for 6 channels in any mode
I've mapped what I can of the X32, and disappointingly for me, only one of the rotary controls (assignable pan knob) sends any MIDI data in any mode that I can discover. Neither, for some strange reason, do the Solo buttons (except some of them in Remote mode).
So, it's not going to be quite as flexible as I hoped, although there are still quite a few faders and buttons (latching and non-latching) which do deliver data, depending on the mode the desk is in.
Hopefully at least the Faders and switches would be useful for me if your project can build a map for it. I might have to look into another general purpose knobs and buttons MIDI controller for FX use as well (ideas please?).
I love my Softube Console 1 for that job
Quote:
Originally Posted by andyp24
Briefly (let me know when/if you want a full list of what sends what):
The one physical Assignable Pan Knob sends 00-7F for up to 64 different channels (according to the Bank and Channel Selects on the desk)
CHANNEL SECTION
8 physical Mute Buttons send 00 or 7F (latching) for up to 64 different channels (according to the Bank Select on the desk)
8 physical Channel Faders send 00-7F (nothing sent when Touched or Released, only CC when moved) for up to 64 channels (according to the Bank Select on the desk)
BUSS SECTION (Normal desk mode)
8 physical Mute Buttons send 00 or 7F (latching) for up to 31 different channels (according to the Bank Select on the desk)
8 physical Channel Faders send 00-7F (nothing sent when Touched or Released, only CC when moved) for up to 31 channels (according to the Bank Select on the desk)
One physical Main Fader sends 00-7F (nothing sent when Touched or Released, only CC when moved) for one channel
BUSS SECTION (DAW Remote mode)
8 physical Select switches send 00 or 7F (non-latching) for 8 channels - Note On/Off
8 physical Solo switches send 00 or 7F (non-latching) for 8 channels - Note On/Off
8 ohysical Mute switches send 00 or 7F (non-latching) for 20 channels - Note On/Off (according to the Bank Select on the desk)
MISC BUTTONS
6 physical Mute Group buttons send 00 or 7F (latching) for 6 channels in any mode
Ok, we need to agree on a data format.
The best one is simply the 3 byte message, preferably in hex like so:
Assignable Pan Knob b0 01 00-7f
If you put that in decimal it's 176 1 0-127
Hex is cleaner because every number is 2 digits.
Here are some examples:
Fader1 e0 00-7f 00-7f
Fader2 e1 00-7f 00-7f
This describes faders that range from e0 00 00 to e0 7f 7f and e1 00 00 to e1 7f 7f.
See how hex clearly indicates the pattern.
You would expect Fader3 to start with e2, Fader4 to start with e3, etc.
Some switches
Solo 90 08 00-7f
Mute 90 10 00-7f
Do you know if you can send midi messages to remotely switch modes on the X32 ?
The notation makes sense so I can map it out that way when you want me to...
I don't know if I can send Bank and Mode select changes to it via MIDI - I'll try to figure it out though.
Console 1 looks cool - but I'm quite heavily invested already in plugins and it looks as though it's really meant just for it's own plugins, not for mapping controllers to 3rd party VSTs. But I could be wrong....?
Console 1 looks cool - but I'm quite heavily invested already in plugins and it looks as though it's really meant just for it's own plugins, not for mapping controllers to 3rd party VSTs. But I could be wrong....?
Not only is it possible to map 3rd party VST's, it's an integral part of this project
Yes I suppose that makes sense! I might wait to see how well your setup works before investing though ��
I can't see any MIDI implementation docs for X32 which suggest that switching modes will be possible. So I guess it's a choice between either Normal or Remote mode, which changes what the right hand part of the desk does?
Unless there's a way for me to test if there's an undocumented command that would do it?
Yes I suppose that makes sense! I might wait to see how well your setup works before investing though ��
I can't see any MIDI implementation docs for X32 which suggest that switching modes will be possible. So I guess it's a choice between either Normal or Remote mode, which changes what the right hand part of the desk does?
Unless there's a way for me to test if there's an undocumented command that would do it?
The more research I do on this, the more I come to believe OSC is worth a look on this guy.
What way will it need to be for the control on the actual MCU?
at the minute I have to be set to next midi device number. If I put the MCU and Control to the same I lose transport control.
What way will it need to be for the control on the actual MCU?
at the minute I have to be set to next midi device number. If I put the MCU and Control to the same I lose transport control.
Yeah, it's messy right now, but soon the midi devices will be chosen in a UI.
I know I said there would be no UI initially, but now I see a way to make at least some of the configuration available in UI form, nice and easy
Sometimes UI's are the most straight forward was to get things done quickly and easily. I know i like a UI here and there. lol
Haha, there was earlier discussion in this thread about how labour resource intensive UI can be, especially cross platform UI.
The original thoughts about how this all went together made UI design a rather daunting task.
So, the plan was to defer UI until later, in order to get something out more quickly to you good folks.
But now, mostly because of the adoption of a naming convention, I think there is a way to do a decent UI for at least some portions of the configuration.
Rotary1 Thresh
Rotary2 Gain
Rotary3 Attack
Rotary4 Release
Rotary5 Ratio
Rotary1Push Bypass
Rotary6 Wet
What about rotary encoder mapped to a small range of the parameter? Like some compressors, that change it's algos, based on a single knob?
Or, vst instruments, which have different articulations mapped to the range parts of the single knob, so it might be useful to map the exact knob values to some buttons?
Or, vice versa, map several parameters to one knob's range, so it would be possible to toggle between several parameters with a simple knob.
Something like this (showing multiple knobs to the single knob).
But, it can also be "multiple buttons to the single knob" or "multiple button to the single button", where repeatedly pressing a single button would toggle a set of fx params that are represented as buttons in the GUI:
Pressing a single button to toggle compressor's ratios:
What about rotary encoder mapped to a small range of the parameter? Like some compressors, that change it's algos, based on a single knob?
Or, vst instruments, which have different articulations mapped to the range parts of the single knob, so it might be useful to map the exact knob values to some buttons?
Or, vice versa, map several parameters to one knob's range, so it would be possible to toggle between several parameters with a simple knob.
Something like this (showing multiple knobs to the single knob).
Definitely some interesting ideas in there, but let's get the pre-alpha out the door first
I was mostly speaking about fx plugmap format's standard.
It might be thoughtful to make it extensive, so if something like the ideas above would come to your mind at some later stages, it won't ruin compatibility with already written plugmaps.
For now, it seems, you only have "control-parm" pairs in plugmaps, which would be, obviously, not enough to cover some non-basic mappings.
With this point of view, Klinke's xml plugmaps are perfect for the task.
I recommend you to watch other midi designer's videos on that channel. There's lots of info about the ways of mapping different parameters to the widgets.
How about creating an iPad / tablet app, specifically for controlling Reaper.? - And all the things discussed in the thread.
This is clearly the way of the future. Several apps already exist for this, allowing you to create any layout you want, working together with cheap hardware such as the iConnectMIDI2+ device.
The "Hexler TouchOSC" looks to be the best right now, but I think that's Apple only.
The "iMidi Patchbay" looks serviceable, but basic.
However, none of these apps are designed specifically for Reaper, of course, and so are a bit cumbersome to work with for anything other than direct VSTi control. (note that I'm basing this opinion solely on reading the manuals, so caveat emptor.)
Regardless,, a similar app, dedicated to Reaper, could of course have lots of templates, and users hear could then submit their own, custom templates as well.
Last edited by Cableaddict; 01-21-2018 at 04:51 PM.
I was mostly speaking about fx plugmap format's standard.
It might be thoughtful to make it extensive, so if something like the ideas above would come to your mind at some later stages, it won't ruin compatibility with already written plugmaps.
For now, it seems, you only have "control-parm" pairs in plugmaps, which would be, obviously, not enough to cover some non-basic mappings.
With this point of view, Klinke's xml plugmaps are perfect for the task.
I recommend you to watch other midi designer's videos on that channel. There's lots of info about the ways of mapping different parameters to the widgets.
One of the main goals of this project is simplicity.
What you are suggesting adds flexibility at the cost of added complexity.
I watched a few of those videos and and saw a lot of complexity and no real world use cases.
Do you have a use case that requires this approach, other than the articulation one you mention a few posts back ?
Even if we decide to add a different format for some reason, we will still provide the ability to use the simple format, which will likely get used over 99% of the time.
How about creating an iPad / tablet app, specifically for controlling Reaper.? - And all the things discussed in the thread.
This is clearly the way of the future. Several apps already exist for this, allowing you to create any layout you want, working together with cheap hardware such as the iConnectMIDI2+ device. "Hexler TouchOSC" looks to be the best right now, but I think that's Apple only. "iMidi Patchbay" looks serviceable, but basic.
However, none of these apps are designed specifically for Reaper, of course, and so are a bit cumbersome to work with for anything other than direct VSTi control. (note that I'm basing this opinion solely on reading the manuals, so caveat emptor.)
Regardless,, a similar app, dedicated to Reaper, could of course have lots of templates, and users hear could then submit their own, custom templates as well.
Yes, the very first post of this thread mentions iPads, etc.
We are at humble beginnings, but eventually hope to get to where you are talking about.
One of the main goals of this project is simplicity.
What you are suggesting adds flexibility at the cost of added complexity.
I watched a few of those videos and and saw a lot of complexity and no real world use cases.
That's why Reaper is a powerful tool. It can be customized in many ways, so almost every user can configure it how he likes.
Quote:
Originally Posted by Geoff Waddington
Do you have a use case that requires this approach, other than the articulation one you mention a few posts back ?
Fine adjustment of the parameters isn't enough? One knob for a full scale (let's say, 0-127) and the other one that would adjust the same parameter's value in -32-32 range, so that the adjustment could be more precise.
Using a button to quickly set parameter to the middle value? Another one for max value. And the third one to quickly turn the knob to zero.
A pair of buttons to adjust the parameter by 5 points (in 0-127 range)?
A single button that would disable/mute 4 out of 5 frequency ranges in EQ?
An encoder that would do the same, i.e., soloing each frequency, or just dimming other frequencies in half?
All the above should be possible to map per plugin.
Quote:
Originally Posted by Cableaddict
Even if we decide to add a different format for some reason, we will still provide the ability to use the simple format, which will likely get used over 99% of the time.
That means that plugmap should have plugin version/type header, at least, so if something major would be added in some version, the plugin itself would know how to handle the outdated plugmaps or, maybe, convert them into the new format.
That's looks good on the surface, but I literally stopped reading as soon as I saw "requires bluetooth to operate."
Bluetooth is one of the few things GUARANTEED to hurt DAW performance. That puts this app completely off the table for serious usage, at least when low latency is desired or required.
How can they not know this?
If they ever wake up, and code it so it can work with the iConnectMIDI2+ device, then I'll eagerly take another look.
The original thoughts about how this all went together made UI design a rather daunting task.
Is this thread not about enabling a controller as a hardware user interface ?
Hence, IMHO, a computer based GUI (e.g. remote) is part of yet another, completely different, and decently complex game, that might or might not be related, but definitively should be - and is - discussed elsewher.
Linear Mode
