Control Surface Configurator -- Sneak Preview

[todd24]

I will map both cubase and the general mode. Unless someone can figure out how to get it working it will probably make more since to use the cubase mode as the csurf already has that info.

[airon]

Looking forward to the next GUI. Nobody better suited to have his head smoke the least. I was pondering what to do and threw some elements around, but had to go out and replenish some burned calories, which had literally gone up in smoke, to no avail either.

It'll be so worth the effort though. I'll try to help in any way I can.

[Geoff Waddington]

Originally Posted by airon

Looking forward to the next GUI

Thanks to you and all the others as well for the input. That's why I wanted to get it out there, just to spark some creativity -- in myself as well.

I've realized the List Boxes simply aren't up to the task -- maybe Tree View, or List View, some drag and drop maybe....

When this was originally conceived the Modifiers and Cyclers were going to be connected to Controls, but then it was realized that they were really much better tied to Action Sets -- I guess I was "stuck in the past" a bit and had interface ideas that reflected that bias.

There's no color coded thing to click on the picture that represents something inside a Control (the Action Sets collection), if that makes any sense -- it's getting late here

THe whole idea of color coded Controls starts to become meaningless when Red things (Modifier Controls) don't hold Cyan things (Modified Controls) at all but rather things (Action Sets) that are within Cyan things (Modified Controls).

Thanks for helping clear my head

[volt]

Great stuff!

I Found a Good picture and the MIDI information for the Frontier Alphatrack:

http://cachepe.samedaymusic.com/medi...4f38eed8c4.jpg

http://www.frontierdesign.com/downlo...Native_1.0.pdf

Im not a programmer, but if theres anything else i can do to help please let me know (yes i have the alphatrack).

Good luck with project!

[yhertogh]

Geoff,

I love what you are doing here for the community. But i dont really understand why you need JPEGs from control surfaces to make this work. Surely this needs a lot of maintenance from your end (I assume you have to integrate the picture and place some controls on top of them as an overlay).

Can I propose a possible extension: A 'Generic Control Surface' mode, which allows the user to add faders, knobs and buttons quite easily. Maybe in the style the I/O window looks like. The user just adds faders 1 to 9, adds 18 buttons, adds 8 knobs, whatever. GUI wise it doesnt need to look too fancy. From that point actionsets can be attached to them.

Another question: how do the actionsets handle operation like banking, alternative modes (send mode, automation modes, etc) ?

Yves

[Geoff Waddington]

Originally Posted by volt

Im not a programmer, but if theres anything else i can do to help please let me know (yes i have the alphatrack)

Please see the post a couple back, the pictures thing is pretty well dead, they're just not effective, so not needed anymore.

I had a very quick glance at the MIDI spec and, like the Tranzport it's very close to the Mackie MCU, have you tried telling Reaper it's an MCU?

Let me know what you find (found?).

[Geoff Waddington]

I love what you are doing here for the community. But I dont really understand why you need JPEGs from control surfaces to make this work

100% correct !

Turns out that the pictures idea is a now a dead code branch.

Can I propose a possible extension: A 'Generic Control Surface' mode, which allows the user to add faders, knobs and buttons quite easily.

As you pointed out in an earlier post, originally there was to be a learn mode -- from the traffic in this thread it's clear that should be put back on the table.

Another question: how do the actionsets handle operation like banking, alternative modes (send mode, automation modes, etc) ?

The list of Reaper Actions will include things that aren't really Reaper Actions, Actions that will never actually make it to Reaper, they will "short circuit" to local functions that handle these sorts of things. They may, of course call Reaper functionality to accomplish this.

[Geoff Waddington]

Thanks for all the great thoughts folks, a very productive weekend !

It's now back to the drawing board with the insights you kind folks have provided.

A few things have become crystal clear:

1. The fundamental "engine" concepts remain sound
2. A learn mode is in high demand
3. The pictures are not necessary, and indeed actually just get in the way of a smooth interface
4. To maintain the flexibility while retaining usability the GUI needs a LOT of work

Stay tuned .....

[yhertogh]

Originally Posted by Geoff Waddington

As you pointed out in an earlier post, originally there was to be a learn mode -- from the traffic in this thread it's clear that should be put back on the table.

And again, i think we dont want to get carried away here. Allow a user to add whatever amount of faders, knobs and buttons they like. Then allow users to 'learn' the midi messages coming in (this can get tricky with 14bit faders e.g., maybe you first ask the user to select a context e.g. 8bit versus 14 bits, etc).

Originally Posted by Geoff Waddington

The list of Reaper Actions will include things that aren't really Reaper Actions, Actions that will never actually make it to Reaper, they will "short circuit" to local functions that handle these sorts of things. They may, of course call Reaper functionality to accomplish this.

Yes thats what i assumed as well. My question was more around the 'if then else's inside the surface. E.g. If I press this button, fader 1 controls track 1, where as if i press this button, it controls track 17. Other use-cases: if i press this button , the faders and knobs now 'show' send/receive information for a given track, etc, etc. Also what you send back to the surface is dependent on a context: this allows you to turn on leds, have leds change color and so on.

So i guess i still have the same question: what are your ideas on tackling this ?

Yves

[Geoff Waddington]

Originally Posted by yhertogh

Then allow users to 'learn' the midi messages coming in (this can get tricky with 14bit faders e.g., maybe you first ask the user to select a context e.g. 8bit versus 14 bits, etc)

Tricky is right, especially when you consider that the MCU family sends out one MIDI message (MSB, LSB are the 14 bits) per fader move and the Faderport and others (01x?) send out TWO MIDI messages per fader move

Yes thats what i assumed as well. My question was more around the 'if then else's inside the surface. E.g. If I press this button, fader 1 controls track 1, where as if i press this button, it controls track 17. Other use-cases: if i press this button , the faders and knobs now 'show' send/receive information for a given track, etc, etc. Also what you send back to the surface is dependent on a context: this allows you to turn on leds, have leds change color and so on.

Well the 2 Bank switches will be assigned to 2 Actions, BankIncrement and BankDecrement and the "stride" (8, 16, 24, etc.) will be determined by how many surfaces you have "ganged" together. In the object model (class diagram) there is an instance of ControlSurface for each hardware unit and a ControlSurfaceManager singleton that manages uber concepts like surface ganging, unit order, that sort of stuff.

Is this what you're asking?

[yhertogh]

Originally Posted by Geoff Waddington

Well the 2 Bank switches will be assigned to 2 Actions, BankIncrement and BankDecrement and the "stride" (8, 16, 24, etc.) will be determined by how many surfaces you have "ganged" together. In the object model (class diagram) there is an instance of ControlSurface for each hardware unit and a ControlSurfaceManager singleton that manages uber concepts like surface ganging, unit order, that sort of stuff.

Is this what you're asking?

I guess so. It still aint clear how you'd tackle different modes (e.g. normal operation versus send configuration versus plugin configuration) and how you'd handle multi-colored leds, but i guess these are secondary questions

[Geoff Waddington]

It still aint clear how you'd tackle different modes (e.g. normal operation versus send configuration versus plugin configuration) and how you'd handle multi-colored leds, but i guess these are secondary questions

Sorry, I only answered the Bank part of your question, the feedback to the surface is a bit trickier...... let's just say we'll tackle first things first and secondary things second

Please don't take that to mean it won't be done, it will just be a little later.

As far as Sends goes, that's just a matter of an Action Set whose Actions call "send" type functions (send volume, etc.) as opposed to the Default Action Set(say Pan). So pressing a Modifier would change the vPots Action Set from "Default" to "Sends".

[Dr Bob]

Hi

Just to say, I would love to use my Yamaha AW16G as a control surface.

I use it to do field recordings, burn off CD's, import, mix in Reaper.

Would just help the workflow ...

I agree that being able to define a "generic" surface would be just fine,
n faders, n buttons, n knobs, transports, n continuous knobs.

Building control surfaces for every controller out there would indeed be a pain and a lot of work ...

db

[Geoff Waddington]

Originally Posted by yhertogh

Can I propose a possible extension: A 'Generic Control Surface' mode, which allows the user to add faders, knobs and buttons quite easily. Maybe in the style the I/O window looks like. The user just adds faders 1 to 9, adds 18 buttons, adds 8 knobs, whatever. GUI wise it doesnt need to look too fancy. From that point actionsets can be attached to them.

Originally Posted by yhertogh

And again, i think we dont want to get carried away here. Allow a user to add whatever amount of faders, knobs and buttons they like. Then allow users to 'learn' the midi messages coming in

Well, I appreciate your notion of simplicity in spirit.

However as I sit down to write this learner, it's more complex than one might imagine.

Let's take buttons as an exmaple.

First off, you have to separate out the various masks (button press / release, etc.).

As well, you have to determine what byte indicates a Control ID.

Then, believe it or not, you have to see if the light for the button is the same message as the button.

For example Faderport lights and buttons have a strange correspondence (likely due to some low level assembly, Atmel, hardware, etc. issue) --

For instance the Play button is

0xA0, 0x06, 0x00

and the Play light is

0xA0, 0x01, 0x00.

If you note carefully you can see that the ID's add up to 7 (0x06 + 0x01) and indeed that is the case for all the others -- but I don't know how software would "guess" that.

Speaking of the Faderport, the Fader sends out 2 messages per move -- B0 00 MSB, and B0 20 LSB to give you the 14 bits.

We really need to name each control as well, so that the user can remember what control they're adding an Action Set to.

I have 3 surfaces here, MCU (reasonable), Tranzport (very MCU like) and Faderport (nuts).

So I am going to make the mapping as painless as possible, while still allowing for these nutso scenarios.

You only have to do the mapping once, thank goodness

[yhertogh]

Originally Posted by Geoff Waddington

Well, I appreciate your notion of simplicity in spirit.

However as I sit down to write this learner, it's more complex than one might imagine.

Let's take buttons as an exmaple.

First off, you have to separate out the various masks (button press / release, etc.).

As well, you have to determine what byte indicates a Control ID.

Then, believe it or not, you have to see if the light for the button is the same message as the button.

For example Faderport lights and buttons have a strange correspondence (likely due to some low level assembly, Atmel, hardware, etc. issue) --

For instance the Play button is

0xA0, 0x06, 0x00

and the Play light is

0xA0, 0x01, 0x00.

If you note carefully you can see that the ID's add up to 7 (0x06 + 0x01) and indeed that is the case for all the others -- but I don't know how software would "guess" that.

Speaking of the Faderport, the Fader sends out 2 messages per move -- B0 00 MSB, and B0 20 LSB to give you the 14 bits.

We really need to name each control as well, so that the user can remember what control they're adding an Action Set to.

I have 3 surfaces here, MCU (reasonable), Tranzport (very MCU like) and Faderport (nuts).

So I am going to make the mapping as painless as possible, while still allowing for these nutso scenarios.

You only have to do the mapping once, thank goodness

I did some changes to the existing faderport plugin and i agree it's utterly nuts.

I think most generic control surfaces uses CCs for everything (0xB0...). Leds can be a problem though e.g. my VS-2480 listens to value 1,2 and 3 of the same CC it sends out, each resulting into a different color. If the led only has one color it requires a value 02. But luckily the CC number is the same it sends and receives from!

Yves

[cdoerman]

Originally Posted by Geoff Waddington

Anything readable is fine.

So the short answer is -- no pass through in the near term but maybe down the road sometime as a future feature.

I just saw this thread. Haven't had a chance to check it out yet but it sounds very promising. Can't wait to get home and play with it tonight. After a quick glance over the thread, it looks like the pass through mode is probably the main thing I would like to see.

I am using Klinke's MCU plugin and it really is fantastic. There are just a few minor things I would like to tweak in it. For example, the F keys are automatically bound to jump to markers. I would prefer to use them for other functions myself.

Unfortunately, when using the Klinke plug-in, Reaper won't recognize those MIDI events to assign to other actions. It makes sense as the csurf plug-in is grabbing them first.

I think a plug-in like you are developing here would be a great way to "filter" out those controls people want to customize and then pass everything else through to another csurf plugin. If you do add this feature, I think a filter mode would be great - or maybe that is the way you were already thinking it would work.

I assume that right now there is no way to assign two csurf plugins to the same midi in/out, right?

Good luck Geoff. Can't wait to check it out tonight!

[Geoff Waddington]

Originally Posted by cdoerman

I think a plug-in like you are developing here would be a great way to "filter" out those controls people want to customize and then pass everything else through to another csurf plugin. If you do add this feature, I think a filter mode would be great - or maybe that is the way you were already thinking it would work.

I assume that right now there is no way to assign two csurf plugins to the same midi in/out, right?

Well..... sort of.

The posts here made it clear to me that a "learn" mode was necessary, so right now I'm concentrating on that.

An interesting side effect is that it might be possible to pass anything that wasn't "learned" through.

Off the top of my head, the most feasible way to do this is deep in the source code itself, the exisiting SDK control surface code, and Klinke's code are both open source I believe.

Now this wouldn't be all that easy, but I think it might be possible.

Alternatively, you could just map the "pass through" stuff to mimic that of the other plugin, then map the rest to your preference.

[cdoerman]

Originally Posted by Geoff Waddington

Now this wouldn't be all that easy, but I think it might be possible.

Alternatively, you could just map the "pass through" stuff to mimic that of the other plugin, then map the rest to your preference.

It's not a huge deal to me so if it isn't something that you get to soon, I'll be ok. Alternately, if you decide it doesn't make sense to do in the long run, then I guess I'll be ok in that situation too...

As for your suggestion, I would consider remapping everything but I can't imagine how long that would take. The MCU support in Klinke's plug-in is already very deep and he is adding more and more each release. The things i would "customize" are relatively minor so I probably won't invest the kind of time necessary to re-invent the wheel when it is already 98% there for me.

That said, I think your plugin will be a huge help to the community and I applaud your efforts! I'll be keeping my eye on your progress and if I have anything productive to contribute, I will do so gladly.

[strinxx]

Hey Geoff!

I just came by to see if this Houston/ Generic-Remote-Controller issue is going somewhere here, and voilà..! Here you are with some really GOOD news!
That's awesome! And for me a huge step forward, leaving Steini's territory!

After reading all those posts here, I'm actually not quite sure if it still helps to send you inthepipeline's work on Houston's midi mapping?

To be honest, I kind of liked the idea with the picture layouts... since we all are used to work on our remotes in a certain kind of way, I found it really cool to work with Houston and Reaper in that exact way, like I used to with Nuendo. At least in the beginning...
But if I would have then the possibility to make it even better, and "build" my remote from scratch, that's cool too!

So let's see, where your configurator ist getting me... I definitely believe Houston could do a great job on Reaper. Thanks so much for your work! Can't wait to see a final release candidate!

Greetings from Munich!

[Geoff Waddington]

Started a new thread on this:

http://forum.cockos.com/showthread.php?t=46265

to represent the "new beginning"