Hi Geoff & Co,
Just scan read thru the thread so far, and reading about the fx mapping, and single file vs file per fx.
I'd would be in the file per fx camp.

Reason being, having played around with Geoff's MCUC4 csurf.
I've rearranged everything in the c4fx.ini file while adding to it.
It wasn't in aphabetical order and I found it quiet cluttered.
The way I reordered things was to Arrange by vendor, then fx, and separate between each vendor

So I know it may come off as ocd, but I feel it speeds things up mapping wise.

I can only imagin the mess some people would leave the file, (judging by friends record collections lol.)

So for me single files or atleast single vendor files would be the way to go.

Imagine getting a new set of plugins, going into a stash and finding the complete maps, download and paste, job done, yeah sure maybe they're not labeled to your liking, but at least the hard work's done.

So what is the correct terminology and format used for the >Mix1, >Mix2, >Control.
(I had Geoff's MCU+C4 installed so just copied the midi(dev#,#) seems to work for the MCU transport but I've nothing in the >Control so I wasn't really expecting much there.

Do these directly refer to (for expamle) MCU, XT, C4?

I'm getting transport function (both ways) straight off, but can't seem to get the faders etc on the MCU, and the c4 is just sitting looking at me lol.

Hi Geoff & Co,
Just scan read thru the thread so far, and reading about the fx mapping, and single file vs file per fx.
I'd would be in the file per fx camp.

Reason being, having played around with Geoff's MCUC4 csurf.
I've rearranged everything in the c4fx.ini file while adding to it.
It wasn't in aphabetical order and I found it quiet cluttered.
The way I reordered things was to Arrange by vendor, then fx, and separate between each vendor

So I know it may come off as ocd, but I feel it speeds things up mapping wise.

I can only imagin the mess some people would leave the file, (judging by friends record collections lol.)

So for me single files or atleast single vendor files would be the way to go.

Imagine getting a new set of plugins, going into a stash and finding the complete maps, download and paste, job done, yeah sure maybe they're not labeled to your liking, but at least the hard work's done.

Maybe I'm too late to the party and that ship has already sailed.

Looking forward to having a play with pre-alpha later.

If we adopt VERY strict naming conventions that will be possible.

I think we should do that, starting right now !

Here's why:

A logical surface is made up of 1 or more physical surfaces (e.g MCU)

You give each surface a name (e.g. MCU1).

Surfaces contain widgets (e.g. Mute button).

You give each widget a name (e.g. MCU1Mute4).

A widget is associated with a MIDI message(e.g. 90 13 7f)

Here is a map entry:

MCU1Mute4 90 13 7f

Now we can make FX map entries with just a key-value pair.

Suppose you want MCU1Mute4 to bypass a certain FX.

Here is a map entry:

MCU1Mute4 Bypass

You have now tied that exact control to that exact parameter.

This makes maps internally consistent and humanly readable, but extremely verbose, and redundant.

The verbose we can deal with in a UI, the redundant is a problem.

Suppose you decide to remap a particular parameter.

That means you must change EVERY INSTANCE in every surface map, ugghhh.

I've been thinking about this a lot lately, and I think the only reasonable way is to adopt naming conventions.

That will be fairly easy for a person or a few, but things get tricky as more get involved.

Well, let's look at what that means.

It means we'll have incompatible naming conventions, making sharing non-trivial.

So, now you have the reasoning behind the extremely simple file format.

With such a format, it will be easy to write conversion tools, whilst still retaining the flexibility of being able to make up your own naming conventions.

Let's start the ball rolling, it's probably as painless as theses few steps:
1) Name the widget exactly as it appears on the surface -- the Play button is named "Play"
2) Name Channel components thusly -- "Fader1, Mute1, Solo1, Fader2, Mute2, Solo2...
3) Naming surfaces will be a bit harder, but a least if you run into a problem a simple text editor search/replace is your friend.

Note that we are just talking about file formats -- NOT user interfaces.

The idea is to get you folks up and running, then tackle the UI.

Getting the file format right will certainly help the UI design of course.

So what is the correct terminology and format used for the >Mix1, >Mix2, >Control.
(I had Geoff's MCU+C4 installed so just copied the midi(dev#,#) seems to work for the MCU transport but I've nothing in the >Control so I wasn't really expecting much there.

Do these directly refer to (for expamle) MCU, XT, C4?

I'm getting transport function (both ways) straight off, but can't seem to get the faders etc on the MCU, and the c4 is just sitting looking at me lol.

Yeah, the C4 won't work until we have a map for it.

The names are up to you, but this a pre-alpha, pre-external map version that has everything hardwired internally, so it needs those surfaces defined. You can use either Mix and put you dev #'s there, you should get faders.

If that "Mute" name should be mandatory for any device, I'm against it.
Not every device has dedicated Mute buttons.
For example, Novation SL doesn't have any labels at all for the most of it's buttons. Instead, buttons are called by corresponding row's letter and button's number (in the programmer's manual, at least). Like A1-A8, B1-B8, C1-C8, D1-D8.
This is how I called all the controls that are available with SL. They were called with full names, initially, but during one of the refactoring phases, I've decided to shorten the names.

My namings for controls, control states and led feedback: https://i.imgur.com/jZgSj7P.png
Bear in mind that I didn't implement LED ring modes in my oscii-bot script, yet, so there would bу some extra lines for those variables, too.

So, I find naming controls by functions counter intuitive, since in many scenarios, those buttons might not be used as "mute".
Also, don't forget about the feedback. Not every device gets button feedback with the same CC that is sent when the button itself was pressed.

I also think that it might be easier to use index numbers in plugmaps, instead of names, for the surfaces. And the surfaces themself would be mapped to the numbers in the main script.
This way, plugmaps could be universal.

Question...
Could it be possible at some point to also alternatively specify the MIDI messages in 'explicit names' and decimal rather than hex ?
So for e.g. '90 13 7f' instead say 'NoteOnChan1 19 127".

Asking, because that's how they're shown in the mapping editor I use for the BCR.

Not a deal breaker, but just be a little more convinient to use the values directly rather than having convert to hex first (which I'm not that fluent in, but would also be manageable of course.)

Question...
Could it be possible at some point to also alternatively specify the MIDI messages in 'explicit names' and decimal rather than hex ?
So for e.g. '90 13 7f' instead say 'NoteOnChan1 19 127".

Asking, because that's how they're shown in the mapping editor I use for the BCR.

Not a deal breaker, but just be a little more convinient to use the values directly rather than having convert to hex first (which I'm not that fluent in, but would also be manageable of course.)

I still don't get it. You're saying that the surface name is used for widgets in plugmaps? Ok. You have MCU and your devices are named as MCU1 and MCU2 in your plugmaps. Now, you're sharing them to me, who has SL and it's named as SLMK2. Does this mean that I should edit all the lines in your plugmaps, changing them from MCU1 to SLMK2? What about MCU2 lines? I should edit them too? If it's true, what's the point of sharing plugmaps? I'd make my own mappings faster than editing and testing someone else's map, though, creating plugmaps for all plugins by yourself will take a huge amount of time from every single user, instead of cooperative work.

IMO, widgets should simply be named as Widget1 - Widget 9999 (like action numbers in Reaper and FX_PARAM_1 in OSC).
Now, when initially creating the main script for their controllers, users will assign those widgets to their liking, specifying the type of the controller and it's possibilities.

Then, we'll eventually come up with some sort of guideline for plugmaps, where, for example, Widget 1 for every EQ plugin should always be LF, Widget 2 LMF, Widget 3 - MF and so on.
For Synth plugins, Widget 1 - filter cutoff, Widget 2 - modulation. There should be around 8-16 common parameters for each type of plugins, which will be always defined the same in each plugmap.

So, the main script entries, related to the plugmaps will look like (pseudocode):

P.S. You said: "Yes, we are not naming by function, we are simply using the name printed on the surface so that everyone uses the same names for the widgets."
Mine doesn't have any "Mute" buttons, BTW. No names at all, apart from a couple of transport icons.
So, I think that no controller dependent things should be mentioned in plugmaps.
Unless you don't want plugmaps to be universal for any device.

I still don't get it. You're saying that the surface name is used for widgets in plugmaps?

No, I'm saying that due to this discussion, I realized it doesn't have to be, thanks !

Quote:

Originally Posted by fundorin

Unless you don't want plugmaps to be universal for any device.

That is correct, a central feature of this project is to provide the ability to map specific controls on specific devices to specific Reaper functions, plugin maps are definitely not universal for any device, nor are they intended to be.

Plugin maps are universal for device/map combos long as naming conventions are followed.

That is correct, a central feature of this project is to provide the ability to map specific controls on specific devices to specific Reaper functions, plugin maps are definitely not universal for any device, nor are they intended to be.

Plugin maps are universal for device/map combos long as naming conventions are followed.

They're definitely should be universal. Otherwise, it makes no sense at all.
And it's possible, just like I've described before.
*.ReaperOSC files are a good example of this approach.
I think that you might want to check oscii-bot for it's mechanics and structure.
It allows multiple midi and osc devices to be configured in the "main" script, so they would work simultaneously. It's also possible to run several "main" scripts for different devices at once with a single instance of the oscii-bot.
And they all would communicate with Reaper via the same .ReaperOSC file.
Of cause, it's possible to create several OSC control surfaces in Reaper, for each oscii-bot script, but I don't think that it would make much sense, tbt.

There should be an initial base template with comments, so that users would edit it and save under the name of the plugin.

Why do you want to create plugmaps for specific consoles, instead of making them universal? What would be the benefit of this approach?

I still don't get it. You're saying that the surface name is used for widgets in plugmaps? Ok. You have MCU and your devices are named as MCU1 and MCU2 in your plugmaps. Now, you're sharing them to me, who has SL and it's named as SLMK2. Does this mean that I should edit all the lines in your plugmaps, changing them from MCU1 to SLMK2? What about MCU2 lines? I should edit them too? If it's true, what's the point of sharing plugmaps? I'd make my own mappings faster than editing and testing someone else's map, though, creating plugmaps for all plugins by yourself will take a huge amount of time from every single user, instead of cooperative work.

IMO, widgets should simply be named as Widget1 - Widget 9999 (like action numbers in Reaper and FX_PARAM_1 in OSC).
Now, when initially creating the main script for their controllers, users will assign those widgets to their liking, specifying the type of the controller and it's possibilities.

Then, we'll eventually come up with some sort of guideline for plugmaps, where, for example, Widget 1 for every EQ plugin should always be LF, Widget 2 LMF, Widget 3 - MF and so on.
For Synth plugins, Widget 1 - filter cutoff, Widget 2 - modulation. There should be around 8-16 common parameters for each type of plugins, which will be always defined the same in each plugmap.

So, the main script entries, related to the plugmaps will look like (pseudocode):

P.S. You said: "Yes, we are not naming by function, we are simply using the name printed on the surface so that everyone uses the same names for the widgets."
Mine doesn't have any "Mute" buttons, BTW. No names at all, apart from a couple of transport icons.
So, I think that no controller dependent things should be mentioned in plugmaps.
Unless you don't want plugmaps to be universal for any device.

Your naming convention A1,A2... would also work well on my Mackie C4, RowA-D knob1-8 and the BCR2000.

Geoff, I would not turn down a starter pack... just to get me into the swing.

On the FX side, working back from the plugin names where does the path diverge depending on surface. Maybe there some way to keep the everything the same for plugins providing the convention has been a dressed somewhere else. (I don't speak progammer talk so please for give my ignorance)

On the FX side, working back from the plugin names where does the path diverge depending on surface. Maybe there some way to keep the everything the same for plugins providing the convention has been a dressed somewhere else. (I don't speak progammer talk so please for give my ignorance)

The FX filename list tells the surface map to include those FX map definitions, as long as we obey the naming conventions -- FX files MUST use widget names that exist in the surface map, we're good to go.

Let's say someone has made a map for the MCU, it is likely sharable with a Behringer X-Touch user or an Icon Qcon user, but likely not a novation SL user, that's what I mean when i say not universal.

I feel like we are talking about different types of maps. Let me see if I understand your approach correctly.

I see this plugin's logic divided in two parts:

1. Main script, describing surface logic. MCU, SL, others. MIDI, OSC, SYSEX, feedback parts are going here. These script aren't universal.
One should map physical controls to the widgets and configure their type in the main script.
The main script should be placed in the folder "Integrator".

2. Plugmaps. These are universal and independent from the surface. They only describe connections between widgets and fx/inst parameters. So, Widgets would store FX parameters data from Reaper (names, values and othert types) in them and would translate midi/osc data to control fx parameters in Reaper and provide feedback to the surfaces.
One can create plugmaps: define the parameters order, their type, like is it a button/fader/selector/list for the specific plugins and share them.

Plugmaps should be placed into "Plugmaps" folder, either freely (root path) or in hierarchy, like /Plugmaps/Vendor/PluginName.txt or /Plugmaps/!Type/PluginName.txt
For example, both /Plugmaps/Arturia/Analog Lab 3.txt and /Plugmap/!EQ/Fabfilter Pro-L2.txt are valid paths. In case of duplicate maps, /!Type/PlugName.txt path has higher priority upon /Vendor/PlugName.txt and plugmap in the root /Plugmaps/ folder has higher priority than both /Vendor/ and /!Type/ subfolder maps. If plugmaps have the same name/id, the newer one would be used by integrator.

The plugin itself should load the needed plugmap, based on the filename or on the first line inside the map, that would have the plugin's name/id. I'd prefer filename, though, since it's easier to rename, in case of renaming the plugin itself inside the Reaper.

The FX filename list tells the surface map to include those FX map definitions, as long as we obey the naming conventions -- FX files MUST use widget names that exist in the surface map, we're good to go.

Why do we need filename list at all?! Why not just scan subfolders for the match? Having filename doubles the work. If it's really needed, it should be generated by integrator itself, based on the folder scan results, like Reaper does with vsts.
It can even automatically create generic plugmaps for each plugin in Reaper, which can later be easily modified by user. It would just scan reaper-vstplugins64.ini, reaper-vstrenames64.ini and reaper-vstshells64.ini files for the info about plugins.

I feel like we are talking about different types of maps. Let me see if I understand your approach correctly.

I see this plugin's logic divided in two parts:

1. Main script, describing surface logic. MCU, SL, others. MIDI, OSC, SYSEX, feedback parts are going here. These script aren't universal.
One should map physical controls to the widgets and configure their type in the main script.

Sort of...

You give widgets names and then map them to Actions.
In this regard Actions are no different than FX, as a matter of fact if you look at the code, you will see that TrackFX_Action is just one of the many actions, it's not different or special in any way from a mapping perspective.

Quote:

Originally Posted by fundorin

The main script should be placed in the folder "Integrator".

Sure, maybe, haven't thought about directory structure quite yet.

Quote:

Originally Posted by fundorin

2. Plugmaps. These are universal and independent from the surface. They only describe connections between widgets and fx/inst parameters.

No, they are required to use only widget names that exist on a given surface, they have a surface context.

Quote:

Originally Posted by fundorin

So, Widgets would store FX parameters data from Reaper (names, values and othert types) in them and would translate midi/osc data to control fx parameters in Reaper and provide feedback to the surfaces.
One can create plugmaps: define the parameters order, their type, like is it a button/fader/selector/list for the specific plugins and share them.

No, widgets don't store anything and plugin parameters do not have a type, you can control a parameter with just about any widget, some make more sense than others, that's all.

Quote:

Originally Posted by fundorin

Plugmaps should be placed into "Plugmaps" folder, either freely (root path) or in hierarchy, like /Plugmaps/Vendor/PluginName.txt or /Plugmaps/!Type/PluginName.txt
For example, both /Plugmaps/Arturia/Analog Lab 3.txt and /Plugmap/!EQ/Fabfilter Pro-L2.txt are valid paths. In case of duplicate maps, /!Type/PlugName.txt path has higher priority upon /Vendor/PlugName.txt and plugmap in the root /Plugmaps/ folder has higher priority than both /Vendor/ and /!Type/ subfolder maps. If plugmaps have the same name/id, the newer one would be used by integrator.

Don't know, once again haven't thought through directory structure, but what you describe looks overly complex and I didn't find the concept of priority very useful in this context (both duplicates and date stamps).

Quote:

Originally Posted by fundorin

The plugin itself should load the needed plugmap, based on the filename or on the first line inside the map, that would have the plugin's name/id. I'd prefer filename, though, since it's easier to rename, in case of renaming the plugin itself inside the Reaper.

Nope, the plugin simply asks if there is a map available, it has no clue about filenames, filesystems, etc.

Quote:

Originally Posted by fundorin

Are we sharing the same vision here or not?

Not sure, at a very general level, yes, but as far as details, we seem quite far apart on some things.

Why do we need filename list at all?! Why not just scan subfolders for the match? Having filename doubles the work. If it's really needed, it should be generated by integrator itself, based on the folder scan results, like Reaper does with vsts.
It can even automatically create generic plugmaps for each plugin in Reaper, which can later be easily modified by user. It would just scan reaper-vstplugins64.ini, reaper-vstrenames64.ini and reaper-vstshells64.ini files for the info about plugins.

This approach makes the presumption that all surfaces should map all plugins, and that all plugin parameters should be included in any given map.

This is definitely not the case, this project is all about customization, a user might not even want to map all plugins to all surfaces or even all parameters of a given plugin, etc.

Once again you seem to be leaning toward a generic/autoload approach, the polar opposite of what this project is trying to accomplish.

Caps (left part) is, let's say, plugin parameters in the integrator. Lower case at the right are "widgets". "Widgets" can be assigned to parameters in different ways. There can be rotary, toggle, on/off, floating value, normalized value, integer, string types and widget can be written in a free form, following the provided template.
The only thing that is missing is the connection between those "widgets" and midi controls.
For now, I'm writing an oscii-bot script, that would tie together my midi controller and those "widgets" from .ReaperOSC file. Everything is going well, so far, except one thing: there's no way to remap widget's order for fx parameters, based on the plugin name.
Not exactly true, though. There is a way, but it would be the same as Geoff is planning to develop for the intergrator - match current plugin name and rearrange controls, based on some section inside the script. And that's a bummer. For now, my script is already over 1500 lines.
Imagine adding at least 16 lines of assignments for every installed plugin. That would be immediately >16000+ lines on my system. And all those lines should be written manually inside the main script.
I don't know, how much time it would take, and how long would oscii-bot load with such big script.
So, this is not an option. That's why I was hoping that integrator could fulfil my needs.

For now, I'm going to experiment with oscii-bot's file access functions. Maybe, it wouldn't be too hard to develop such thing, using oscii-bot an EEL2 (meh!).
It would still require writing maps manually, but I can do this for my most used plugins, I hope.

As for the integrator, I simply give up. Good luck with your project, Geoff, and Happy New Year! 🎄��🎄

The only thing that is missing is the connection between those "widgets" and midi controls.
For now, I'm writing an oscii-bot script, that would tie together my midi controller and those "widgets" from .ReaperOSC file. Everything is going well, so far, except one thing: there's no way to remap widget's order for fx parameters, based on the plugin name.
Not exactly true, though. There is a way, but it would be the same as Geoff is planning to develop for the intergrator - match current plugin name and rearrange controls, based on some section inside the script. And that's a bummer. For now, my script is already over 1500 lines.

For now, I'm going to experiment with oscii-bot's file access functions. Maybe, it wouldn't be too hard to develop such thing, using oscii-bot an EEL2 (meh!).
It would still require writing maps manually, but I can do this for my most used plugins, I hope.

As for the integrator, I simply give up. Good luck with your project, Geoff, and Happy New Year! 🎄��🎄

Yeah, I've had the feeling for a while that the 2 projects are quite similar, but take markedly different approaches.

Thanks for stopping by, it's been helpful, and if i can do anything to help on your project, don't be shy, all the best and Happy New Year !!

It really does look very straightforward, pity it couldn't be universal, but if it works the way you've explained it, it will be awesome.

PS. HAPPY NEW YEAR!!!

Well it's not that bad, it's really quite close to universal, if you think about it.

If someone made an FX map for a Behringer X-Touch, it is reasonable that it could be shared with MCU users, as long as both users conformed to the widget naming conventions.
The physical surfaces are very similar as far as widgets and layout are concerned.

However, it is highly unlikely an MCU user could share an FX map that was made for a Console 1.
But that's OK and makes perfect sense, an MCU surface and a Console 1 surface are not anywhere near alike, so the mappings are likely incompatible from an ergo/workflow standpoint anyway.

So, maps that see the world the same way (MCU, X-Touch, Faderport 8, etc.) ARE sharable (universal) and that's what really counts.

I was playing around today, MCU PRO (USB midi onboard) the mcu faders are running off midi 3,4,
Control (which I've come to believe is transport) needs set to 4,5
Does that mean the faders and trans are not on the same port,
The master doesn't work, but if I press the bank left button, the faders change , one stays up, and that one works the master.

How do I get pan values displayed?

I've been looking at the midi values for the C4, all written down, any suggestions as to ere to start mapping wise?

I was playing around today, MCU PRO (USB midi onboard) the mcu faders are running off midi 3,4,
Control (which I've come to believe is transport) needs set to 4,5
Does that mean the faders and trans are not on the same port,
The master doesn't work, but if I press the bank left button, the faders change , one stays up, and that one works the master.

That's because the surfaces named Mix and Control are actually Avid Artist series physical surfaces in Mackie Control mode, so the transport is on the Control, a separate device, that's why the number strangeness.

Don't worry too much about this, it will all clear up when real external maps are implemented.

Quote:

Originally Posted by Freex

How do I get pan values displayed?

The pan should show on the rings and should change styles when the top is pushed and you have a track that is set to stereo pan.

Quote:

Originally Posted by Freex

I've been looking at the midi values for the C4, all written down, any suggestions as to where to start mapping wise?

i would do as fundorin suggested, it's pretty much a standard style for matrix type surfaces.

I have a Behringer XControl Compact which I use for other purposes (Live Playing).

It might be nice to use it for mixing of multitrack recordings, as well, which I just sometimes do.

It does feature a "Mackie" mode, that might be applicable, but I did not try that yet.

I'm not holding my breath but with the arising "map" features, Controller Board usage seems to get flexible and interesting, so I'm holding off trying the Mackie mode but wait until an "official" version (including naming convention etc) of the controller map implementation is available.

I have a Behringer XControl Compact which I use for other purposes (Live Playing).

It might be nice to use it for mixing of multitrack recordings, as well, which I just sometimes do.

It does feature a "Mackie" mode, that might be applicable, but I did not try that yet.

I'm not holding my breath but with the arising "map" features Controller Board usage seems to get flexible and interesting, so I'm holding off trying the Mackie mode but wait until an "official" version (including naming convention etc) of the controller map implementation is available.

Thanks a lot for your work !
-Michael

Yes, that surface should be a very good test candidate, hope you join in the beta testing when it starts.

Makes sense to not narrow it down to rows, with a defined number of slots.

Cool.

Would I be right to assume that "Fader1 Touch" should also change to "FaderTouch 1"? Again witha view to simplifying things.

Also not seeing any pan or width values on the display? Track name only.

Maybe a finishing touch for later, but is there a way to have all the faders drop down to silence position, and all buttons & displays clear, when you exit Reaper? Would be a nice "I'm finished turn me off". lol

Makes sense to not narrow it down to rows, with a defined number of slots.

Cool.

Would I be right to assume that "Fader1 Touch" should also change to "FaderTouch 1"? Again witha view to simplifying things.

Yes.

Quote:

Originally Posted by Freex

Also not seeing any pan or width values on the display? Track name only.

Ahh, correct, but you do see the LED rings indicating value, right, ?

Quote:

Originally Posted by Freex

Maybe a finishing touch for later, but is there a way to have all the faders drop down to silence position, and all buttons & displays clear, when you exit Reaper? Would be a nice "I'm finished turn me off". lol

Of course, the goal for the pre alpha is a basic functionality test, niceties like clear to follow...