Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old 12-27-2017, 04:55 AM   #401
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

That sounds awesome Geoff! Thank you Santa and Happy Holidays!
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 12-29-2017, 06:14 AM   #402
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

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

-------------- AVendor Afx name ------------
FX|Vst.........
BW.......
EQ.......
-------------- AVendor Bfx name ------------
FX|Vst.........
S2......
SR......
--
--
--
-------------- BVendor Afx name ---------------
FX|VST....

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.

Last edited by Freex; 12-29-2017 at 06:12 PM.
Freex is online now   Reply With Quote
Old 12-31-2017, 03:06 AM   #403
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

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.
Freex is online now   Reply With Quote
Old 12-31-2017, 03:42 AM   #404
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
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

-------------- AVendor Afx name ------------
FX|Vst.........
BW.......
EQ.......
-------------- AVendor Bfx name ------------
FX|Vst.........
S2......
SR......
--
--
--
-------------- BVendor Afx name ---------------
FX|VST....

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.

Open to any ideas...
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 03:47 AM   #405
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 04:50 AM   #406
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

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.
fundorin is offline   Reply With Quote
Old 12-31-2017, 06:01 AM   #407
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
If that "Mute" name should be mandatory for any device, I'm against it.
Not every device has dedicated Mute buttons.
Hmmm. must not be explaining this well, let me try again.

I'm suggesting that if the button says Mute on the surface you name it "Mute".

if there is no Mute button you don't name anything Mute.

We are NOT attempting to designate function here, but rather, to simply come up with common language for naming widgets.

So everyone that has MCU's would name their widgets the same, everyone who had novation SL's would name theirs the same, etc.

Quote:
Originally Posted by fundorin View Post
So, I find naming controls by functions counter intuitive, since in many scenarios, those buttons might not be used as "mute".
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.

As you say there is no guarantee or requirement that Mute gets to do Mute, that's just one of many possibilities.

The whole exercise is to facilitate sharing maps, that's all.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 08:33 AM   #408
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Quote:
Originally Posted by Geoff Waddington View Post
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.
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.)

Last edited by nofish; 12-31-2017 at 08:39 AM.
nofish is offline   Reply With Quote
Old 12-31-2017, 08:42 AM   #409
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Aha, think it's becoming clear...

If we adhere to the naming convention we can indeed eliminate the surface name from the map file.

Here's an example of the problem I was trying to deal with when maps span surfaces:

MCU1Mute4 Bypass
MCU2Mute4 CompLim
MCU3Mute4 HPF

That can be solved by breaking it into 3 maps
Mute4 Bypass -- call it FX1.map
Mute4 CompLim -- FX2.map
Mute4 HPF -- FX3.map

then we can add FX1.map to the MCU1 map, the FX2.map to the MCU2 map, etc.

We can supply folks with "starter" maps -- e.g. a map for all the widgets of an MCU.

These can be paired with maps that speak the same "dialect", that is maps that use the same set of names (widget and FX), voila, nice and simple.

Now you just have to add lists of FX filenames to your surface maps.

We still retain full flexibility, widget naming convention makes it work.

Anyone see anything wrong here ?
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 08:44 AM   #410
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by nofish View Post
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.)
Good point we should probably parse either, I think that's possible.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 08:59 AM   #411
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

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):
Code:
in fx_mode (
  Encoder1 = Widget1, type(enc,L64+,R1+,relative,range=0.5)
  Encoder2 = Widget2, type(enc,L(65,127),R(1,63),relative,range=1)
  ...
  Encoder3 = Widget3, type(enc,L64+,R1+,absolute,accel=2)
  ...
  Pot1 = Widget9, type(pot,absolute,range=1)
  ...
  Pot7 = Widget5, type(pot,range=(2-126),invert)
  Pot8 = Widget16, type(pot,softpickup,range=(65-127))
  Pot8 = Widget17, type(pot,softpickup,range=(64-0))

  else if shift_is_pressed (
    Encoder1 = Widget17, type(enc, blabla)
    ...
    Pot8 = = Widget32, type(pot, blabla)
  ) 
)
note how Pot8 is mapped for two different widgets

plugmap:
Code:
Widget1 = Param1, long = "Soundgoodizer", short = "Good", dispvalue = "Hz", step = 5
Widget2 = Param6, long = "Wet/Dry", short = "Wet/Dry", dispvalue = "%"
...
Widget32 = Param2, long = "UseLESS", short = "uLESS", dispvalue = "dummies", step = 0
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.

Last edited by fundorin; 12-31-2017 at 10:05 AM.
fundorin is offline   Reply With Quote
Old 12-31-2017, 09:02 AM   #412
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Quote:
Originally Posted by Geoff Waddington View Post
Good point we should probably parse either, I think that's possible.
Cool, thanks for considering.
nofish is offline   Reply With Quote
Old 12-31-2017, 10:29 AM   #413
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
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 View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 12-31-2017 at 10:40 AM.
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 10:51 AM   #414
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

Quote:
Originally Posted by Geoff Waddington View Post
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?
fundorin is offline   Reply With Quote
Old 12-31-2017, 11:02 AM   #415
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Quote:
Originally Posted by fundorin View Post
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):
Code:
in fx_mode (
  Encoder1 = Widget1, type(enc,L64+,R1+,relative,range=0.5)
  Encoder2 = Widget2, type(enc,L(65,127),R(1,63),relative,range=1)
  ...
  Encoder3 = Widget3, type(enc,L64+,R1+,absolute,accel=2)
  ...
  Pot1 = Widget9, type(pot,absolute,range=1)
  ...
  Pot7 = Widget5, type(pot,range=(2-126),invert)
  Pot8 = Widget16, type(pot,softpickup,range=(65-127))
  Pot8 = Widget17, type(pot,softpickup,range=(64-0))

  else if shift_is_pressed (
    Encoder1 = Widget17, type(enc, blabla)
    ...
    Pot8 = = Widget32, type(pot, blabla)
  ) 
)
note how Pot8 is mapped for two different widgets

plugmap:
Code:
Widget1 = Param1, long = "Soundgoodizer", short = "Good", dispvalue = "Hz", step = 5
Widget2 = Param6, long = "Wet/Dry", short = "Wet/Dry", dispvalue = "%"
...
Widget32 = Param2, long = "UseLESS", short = "uLESS", dispvalue = "dummies", step = 0
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)

Last edited by Freex; 12-31-2017 at 11:08 AM.
Freex is online now   Reply With Quote
Old 12-31-2017, 11:42 AM   #416
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
They definitely should be universal. Otherwise, it makes no sense at all.
Depends on your definition of universal.

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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 11:53 AM   #417
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
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)
Ok so in "pseudo map speak"

FXMap -- file is named Compressor.map
Fader1 Threshold
Fader2 Gain
Fader6 Meter

FXMap -- file is named EQ.map
Fader3 LoFreq
Fader4 MidFreq
Fader5 HiFreq

//////////////////////////////////////////
Surface map named "MCU1"
Fader1 Fader14Bit e0 7f 7f
Fader2 Fader14Bit e1 7f 7f
Fader3 Fader14Bit e2 7f 7f
Fader4 Fader14Bit e3 7f 7f
Fader5 Fader14Bit e4 7f 7f
Fader6 Fader14Bit e5 7f 7f
Fader7 Fader14Bit e6 7f 7f
Fader8 Fader14Bit e7 7f 7f

// filename list
Compressor.map
EQ.map
/////////////////////////////////////////

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.

Also notice how simple the maps become.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 12-31-2017 at 12:35 PM.
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 12:55 PM   #418
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

Quote:
Originally Posted by Geoff Waddington View Post
Depends on your definition of universal.

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.

Are we sharing the same vision here or not?
fundorin is offline   Reply With Quote
Old 12-31-2017, 12:58 PM   #419
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

Quote:
Originally Posted by Geoff Waddington View Post
// filename list
Compressor.map
EQ.map
/////////////////////////////////////////

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.
fundorin is offline   Reply With Quote
Old 12-31-2017, 02:32 PM   #420
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 02:37 PM   #421
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 03:13 PM   #422
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

I'm starting to understand the direction you guys a re coming at this, universal map vs surface specific map.

What if you had a term in the middle that was universal, that maps could be written in.
Fader1 = C1 = MCUfader1,

Maybe if on every device strating top left,
Pots were P,
Button/switches S
Faders F

So on a MCU and XT you'd have
Vpot(pan) P1-8
RecArm button S1-8
Solo button S9-16
Mute button S17-24
Select button S25-32
Faders F1-8

On C4
Vpot P1-32
Vpot(push) S1-32 (as the vpots are also buttons/swtiches.

On SLMK2
Button S1-8
Faders F1-8
Vpot P1-8
Button S9-16
Etc.

So a switch would always be a switch, a fader always a fader etc.

But for any fx you would get a working map, right out the box.
It might not be to your liking but it would be instantly usable.

Just trying to think outside the box.
It is most like completely impractical, just throwing to see if anything sticks.lol
Freex is online now   Reply With Quote
Old 12-31-2017, 03:45 PM   #423
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
I'm starting to understand the direction you guys a re coming at this, universal map vs surface specific map.

What if you had a term in the middle that was universal, that maps could be written in.
Fader1 = C1 = MCUfader1,

Maybe if on every device strating top left,
Pots were P,
Button/switches S
Faders F

So on a MCU and XT you'd have
Vpot(pan) P1-8
RecArm button S1-8
Solo button S9-16
Mute button S17-24
Select button S25-32
Faders F1-8

On C4
Vpot P1-32
Vpot(push) S1-32 (as the vpots are also buttons/swtiches.

On SLMK2
Button S1-8
Faders F1-8
Vpot P1-8
Button S9-16
Etc.

So a switch would always be a switch, a fader always a fader etc.

But for any fx you would get a working map, right out the box.
It might not be to your liking but it would be instantly usable.

Just trying to think outside the box.
It is most like completely impractical, just throwing to see if anything sticks.lol
Take a look at the following maps:

FXMap -- file is named Compressor.map
// Associate the widgets with FX params
Fader1 Threshold
Fader2 Gain
Fader6 Meter
Mute6 Bypass

FXMap -- file is named EQ.map
// Associate the widgets with FX params
Fader3 LoFreq
Fader4 MidFreq
Fader5 HiFreq
Mute6 Bypass

//////////////////////////////////////////
Surface map named "MCU1"

// Name the widgets, state their type, and indicate which midi message they send
Fader1 Fader14Bit e0 7f 7f
Fader2 Fader14Bit e1 7f 7f
Fader3 Fader14Bit e2 7f 7f
Fader4 Fader14Bit e3 7f 7f
Fader5 Fader14Bit e4 7f 7f
Fader6 Fader14Bit e5 7f 7f
Fader7 Fader14Bit e6 7f 7f
Fader8 Fader14Bit e7 7f 7f

Fader1Touch PushButton 90 68 7f
Fader2Touch PushButton 90 69 7f
Fader3Touch PushButton 90 6a 7f
Fader4Touch PushButton 90 6b 7f
Fader5Touch PushButton 90 6c 7f
Fader6Touch PushButton 90 6d 7f
Fader7Touch PushButton 90 6e 7f
Fader8Touch PushButton 90 6f 7f

Mute1 PushButton 90 10 7f
Mute2 PushButton 90 11 7f
Mute3 PushButton 90 12 7f
Mute4 PushButton 90 13 7f
Mute5 PushButton 90 14 7f
Mute6 PushButton 90 15 7f
Mute7 PushButton 90 16 7f
Mute8 PushButton 90 17 7f


// Associate the widgets with actions
Fader1 TrackVolume
Fader2 TrackVolume
Fader3 TrackVolume
Fader4 TrackVolume
Fader5 TrackVolume
Fader6 TrackVolume
Fader7 TrackVolume
Fader8 TrackVolume

Fader1Touch TrackTouch
Fader2Touch TrackTouch
Fader3Touch TrackTouch
Fader4Touch TrackTouch
Fader5Touch TrackTouch
Fader6Touch TrackTouch
Fader7Touch TrackTouch
Fader8Touch TrackTouch

Mute1 TrackMute
Mute2 TrackMute
Mute3 TrackMute
Mute4 TrackMute
Mute5 TrackMute
Mute6 TrackMute
Mute7 TrackMute
Mute8 TrackMute

// filename list
Compressor.map
EQ.map
/////////////////////////////////////////

See where the type is mentioned ?

That's right, ONLY the widget (Fader14bit, PushButton).

There is no need to differentiate between switches, vpots, faders etc,. EXCEPT right at the widget definition.

Putting a term in the middle doesn't do much except make things more confusing, at least to me.

The final maps really will look this simple, there is no need for any more than that to fully describe the system.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 03:55 PM   #424
fundorin
Banned
 
Join Date: Feb 2014
Location: Moscow, Russia
Posts: 554
Default

All of this was already invented and working nearly fine in OSC format in Reaper.

Code:
FX_NAME s/fx/name s/fx/@/name s/track/@/fx/@/name
FX_NUMBER s/fx/number/str s/fx/@/number/str s/track/@/fx/@/number/str
FX_BYPASS b/fx/bypass b/fx/@/bypass b/track/@/fx/@/bypass 
FX_OPEN_UI b/fx/openui b/fx/@/openui b/track/@/fx/@/openui

FX_PRESET s/fx/preset s/fx/@/preset s/track/@/fx/@/preset
FX_PREV_PRESET t/fx/preset- t/fx/@/preset- t/track/@/fx/@/preset-
FX_NEXT_PRESET t/fx/preset+ t/fx/@/preset+ t/track/@/fx/@/preset+

FX_PARAM_NAME s/fxparam/@/name s/fx/@/fxparam/@/name
FX_WETDRY n/fx/wetdry n/fx/@/wetdry n/track/@/fx/@/wetdry
FX_WETDRY s/fx/wetdry/str s/fx/@/wetdry/str s/track/@/fx/@/wetdry/str
FX_PARAM_VALUE n/fxparam/@/value n/fx/@/fxparam/@/value n/track/@/fx/@/fxparam/@/value
FX_PARAM_VALUE s/fxparam/@/value/str s/fx/@/fxparam/@/value/str
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! 🎄��🎄
fundorin is offline   Reply With Quote
Old 12-31-2017, 04:10 PM   #425
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by fundorin View Post
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 !!
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 12-31-2017, 04:30 PM   #426
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Quote:
Originally Posted by Geoff Waddington View Post
Take a look at the following maps:

FXMap -- file is named Compressor.map
// Associate the widgets with FX params
Fader1 Threshold
Fader2 Gain
Fader6 Meter
Mute6 Bypass

FXMap -- file is named EQ.map
// Associate the widgets with FX params
Fader3 LoFreq
Fader4 MidFreq
Fader5 HiFreq
Mute6 Bypass

//////////////////////////////////////////
Surface map named "MCU1"

// Name the widgets, state their type, and indicate which midi message they send
Fader1 Fader14Bit e0 7f 7f
Fader2 Fader14Bit e1 7f 7f
Fader3 Fader14Bit e2 7f 7f
Fader4 Fader14Bit e3 7f 7f
Fader5 Fader14Bit e4 7f 7f
Fader6 Fader14Bit e5 7f 7f
Fader7 Fader14Bit e6 7f 7f
Fader8 Fader14Bit e7 7f 7f

Fader1Touch PushButton 90 68 7f
Fader2Touch PushButton 90 69 7f
Fader3Touch PushButton 90 6a 7f
Fader4Touch PushButton 90 6b 7f
Fader5Touch PushButton 90 6c 7f
Fader6Touch PushButton 90 6d 7f
Fader7Touch PushButton 90 6e 7f
Fader8Touch PushButton 90 6f 7f

Mute1 PushButton 90 10 7f
Mute2 PushButton 90 11 7f
Mute3 PushButton 90 12 7f
Mute4 PushButton 90 13 7f
Mute5 PushButton 90 14 7f
Mute6 PushButton 90 15 7f
Mute7 PushButton 90 16 7f
Mute8 PushButton 90 17 7f


// Associate the widgets with actions
Fader1 TrackVolume
Fader2 TrackVolume
Fader3 TrackVolume
Fader4 TrackVolume
Fader5 TrackVolume
Fader6 TrackVolume
Fader7 TrackVolume
Fader8 TrackVolume

Fader1Touch TrackTouch
Fader2Touch TrackTouch
Fader3Touch TrackTouch
Fader4Touch TrackTouch
Fader5Touch TrackTouch
Fader6Touch TrackTouch
Fader7Touch TrackTouch
Fader8Touch TrackTouch

Mute1 TrackMute
Mute2 TrackMute
Mute3 TrackMute
Mute4 TrackMute
Mute5 TrackMute
Mute6 TrackMute
Mute7 TrackMute
Mute8 TrackMute

// filename list
Compressor.map
EQ.map
/////////////////////////////////////////

See where the type is mentioned ?

That's right, ONLY the widget (Fader14bit, PushButton).

There is no need to differentiate between switches, vpots, faders etc,. EXCEPT right at the widget definition.

Putting a term in the middle doesn't do much except make things more confusing, at least to me.

The final maps really will look this simple, there is no need for any more than that to fully describe the system.
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!!!
Freex is online now   Reply With Quote
Old 01-01-2018, 04:40 PM   #427
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 01-01-2018 at 04:48 PM.
Geoff Waddington is offline   Reply With Quote
Old 01-01-2018, 05:33 PM   #428
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

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?
Freex is online now   Reply With Quote
Old 01-01-2018, 06:01 PM   #429
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
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 View Post
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 View Post
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.

So map the rotaries, push top switches, and displays thusly:

// push top switches
A1Switch
A2Switch
A3Switch
A4Switch
A5Switch
A6Switch
A7Switch
A8Switch
...
D8Switch


// rotaries
A1Rotary
...
D8Rotary

// displays
A1Display
...
D8Display

I think if we come up with very simple naming conventions this whole idea will work quite well.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 01-01-2018, 06:14 PM   #430
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Cool, i'll work with that naming convention, and see how I get on.

Last edited by Freex; 01-01-2018 at 07:16 PM.
Freex is online now   Reply With Quote
Old 01-02-2018, 01:29 AM   #431
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

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

Last edited by mschnell; 01-02-2018 at 05:04 AM.
mschnell is offline   Reply With Quote
Old 01-02-2018, 02:31 AM   #432
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
Cool, i'll work with that naming convention, and see how I get on.
Hmmm... now that I've had a sleep...

I see what I told you is wrong,

MCU names look like:
Fader1
Mute4
Rotary6

So C4 should follow that conventionn:
SwitchA1
SwitchC7
RotaryD2
DisplayB4

Sorry 'bout that
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 01-02-2018, 02:35 AM   #433
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by mschnell View Post
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.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 01-02-2018, 02:36 AM   #434
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Quote:
Originally Posted by Geoff Waddington View Post
Hmmm... now that I've had a sleep...

I see what I told you is wrong,

MCU names look like:
Fader1
Mute4
Rotary6

So C4 should follow that conventionn:
SwitchA1
SwitchC7
RotaryD2
DisplayB4

Sorry 'bout that
No problem Geoff, I'll see how I get on later today.
Thanks for the update.

Any idea what the display settings would/should look like?
Or how I would figure that end of things out?
Freex is online now   Reply With Quote
Old 01-02-2018, 03:18 AM   #435
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
No problem Geoff, I'll see how I get on later today.
Thanks for the update.

Any idea what the display settings would/should look like?
Or how I would figure that end of things out?
A display needs a slot if it is channel-like -- see example below

Meanwhile...
Another penny dropped...

Here's a superior widget naming convention that could facilitate wider map sharing, and generally make the map less verbose:

MCU
Fader 1
Fader 2
Fader 3
Fader 4

Mute 1
Mute 2
Mute 3
Mute 4

// Action associations become much more compact
Fader TrackVolume
Mute TrackMute

// Actions can still have specific assignments, so we don't lose flexibility
Fader 9 TrackMasterVolume

C4
Rotary 1
Rotary 2
Switch 14 // 6th switch on second row - equivalent of B6 in the old naming convention
Display 7

Now FX maps
FXMap -- file is named Compressor.map
// Associate the widgets with FX params
Fader 1 Threshold
Fader 2 Gain
Fader 6 Meter
Mute 6 Bypass

FXMap -- file is named EQ.map
// Associate the widgets with FX params
Fader 3 LoFreq
Fader 4 MidFreq
Fader 5 HiFreq
Mute 6 Bypass

Subject to change, mostly towards simplicity were possible
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 01-02-2018 at 03:33 AM.
Geoff Waddington is offline   Reply With Quote
Old 01-02-2018, 03:54 AM   #436
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Ok so just switch and rotary 1 thru to 32.

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

Last edited by Freex; 01-02-2018 at 05:02 AM.
Freex is online now   Reply With Quote
Old 01-02-2018, 05:06 AM   #437
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yes, that surface should be a very good test candidate, hope you join in the beta testing when it starts.
Of course I'll do so. To be sure, please send me a private message with instructions, once you want me to start testing.

-Michael
mschnell is offline   Reply With Quote
Old 01-02-2018, 05:39 AM   #438
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
Ok so just switch and rotary 1 thru to 32.

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 View Post
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 View Post
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...
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 01-02-2018, 06:35 AM   #439
Freex
Human being with feelings
 
Freex's Avatar
 
Join Date: Jul 2011
Location: Northern Ireland
Posts: 903
Default

Quote:
Originally Posted by Geoff Waddington View Post


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

Correct, pan and width indicated on the leds only currently.



Will the "Fader 1" naming convention work in the current version?


I thought maybe it needed to be "nospaces" eg. "Fader-1" "Fader_1"



ALSO I can't seem to get the Master track(reaper) on the master track(MCU), it keeps coming up as one of the 8 faders depending on how many times I press bank. Any ideas?

Last edited by Freex; 01-02-2018 at 06:51 AM.
Freex is online now   Reply With Quote
Old 01-02-2018, 07:14 AM   #440
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by Freex View Post
Correct, pan and width indicated on the leds only currently.
Ok, that's as far as that's been developed so far.


Quote:
Originally Posted by Freex View Post
Will the "Fader 1" naming convention work in the current version?
If you mean the pre alpha you have , no.


Quote:
Originally Posted by Freex View Post
ALSO I can't seem to get the Master track(reaper) on the master track(MCU), it keeps coming up as one of the 8 faders depending on how many times I press bank. Any ideas?
Once again trapped by hardwiring, the Avid Artist Mixes have only 8 faders, so there is no mapping for the 9th fader, the Master fader on a regular MCU.

Obviously this will not be the case when we have real maps.

I certainly wouldn't waste much effort trying to get the build that you have operational, experimentation is fine though, just want to set expectations properly, that is ancient code
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 09:25 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.