Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Wiki-- thanks @MalcolmG for getting it going
Video -- thanks @poetnprophet, @EpicSounds, @UNdark, @Navelpluisje and others
Config files -- thanks @siniarch



Edit: You can now donate via PayPal, see link in my sig below.

Following a bit of discussion in the Feature Request subforum (http://forum.cockos.com/showthread.php?t=179220), I have decided to take on the task of improving support in this area.

This is an open call for feature requests, overall philosophies, dream/cadillac solutions, etc.

Just trying to get a feel for what we should attempt to build here.

Nothing is off the table, it should be MUCH easier than the EuCon support project, because it is comparatively unconstrained.

For example: don't even know if this is possible yet, but imagine being able to control the faders from an MCU, the transport from an Artist Transport, and the VST compressors, EQ's, reverbs, etc. from an iPad (perhaps using OSC).

 [edit Aug 28 2019] After close to 3 years we can say we have taken the first steps :)

https://www.youtube.com/watch?v=byqW...ature=youtu.be

That's the kind of open free thinking I'd like to promote here.

From that we can derive a "doable" project.

Have at 'er folks, this only works if you participate.

[DrFrankencopter]

I will contribute more later, but here's what I'd be looking for:
1) Extender support for plugin control please (more than 9 faders)
2) Double click rewind brings transport to 0:00:00, and double click fast forward brings the transport to the end of the project ("Did you want to hear that back from the top?)
3) Easy plug-in control mapping
4) Support for fader/pan 'flip' in plug-in control mode
5) Ability to assign faders to the control surface and have them identified by colour in reaper. E.g. maybe I want Bass, Kick, Snr, Rest of Kit, GTRs, LdVox, BGV, FX1, FX2, and not a bunch of sub folder tracks.

Cheers

Kris

[DrFrankencopter]

Originally Posted by Geoff Waddington

For example: don't even know if this is possible yet, but imagine being able to control the faders from an MCU, the transport from an Artist Transport, and the VST compressors, EQ's, reverbs, etc. from an iPad (perhaps using OSC).

I think this would work. At one point in time I tested using Klinke's csurf dll (the one that supported extenders, I forget the version no.) on my hardware MCU, and on Neyrink V-control at the same time. It worked. I can't image why throwing OSC into the mix wouldn't work too.

Cheers

Kris

[semiquaver]

some ideas in no particular order ...

Eucon's "wheel actions" which you can map to the the jog shuttle wheel were very interesting: I would have loved being able to use the wheel to jog, zoom, trim, nudge, move envelope points up and down, select next item, track, point etc.

I would love to be able to lock tracks to faders, and to have faders write to selected envelope on their track... being able to cycle through envelopes with the wheel would make that very powerful.

It would be very amazing to have compressor gain reduction meters (ok that's too much I'm sure)...

being able to open the first, next plug per track and have the params spill

[semiquaver]

and also a giant prospective thank you !

[flipotto]

I have gotten really attached to klinke's folder diving with select.
Please include that.

[nofish]

I'm copying my post from the other thread here so it's all in one place.

- automateable sends
https://bitbucket.org/Klinkenstecker...tion-for-sends

- a 'follow plugin' mode
https://bitbucket.org/Klinkenstecker...ollows-touched

- a 'native' (built in the .dll) MCU display emu (for those using an MCU emu without built in display, like me with the BCR2000)
Not a high priority as the Mountain utilities BC manager contains an MCU display emu that's working nicely (for me anyways). A built in display emu would eliminate the necessity for virtual MIDI connections though.

- Nice might also be if the tracks currently controlled by the MCU could automatically change to some custom color.

- Some reporting performance decrease with higher track counts using Klinke's .dll
http://forum.cockos.com/showpost.php...2&postcount=39

(haven't experienced personally though, as my track count usually isn't that high)

[Win Conway]

A Synthedit like compiler.
So take all the things that are possible in Reapers controller SDK, put them in graphical compiler form.
This way we can create our own controller support designed specifically around the controllers we have.

[Geoff Waddington]

OK, some VERY PRELIMINARY thoughts:

Support logical aggregation of control surfaces
e.g. an iPad controlling VST's and an MCU controlling faders. pan, etc.
Each controller is aware of its neighbours, itself, and its role in the "community aggregate".

Support numerous workflow configurations, often by pruning functionality -- anyone not hiding the playrate control ?

Support scripting -- EEL/JSFX/Lua/Python, etc.

Support the usual controller specific suspects -- midi learn, etc.

Support more than just MIDI -- support OSC etc.

Coming up with the functionality is more than trivial, but that pales in comparison to the effort required to get a workable UI for all this.

I certainly hope all of you out there will jump in with the great ideas needed for success.

[mschnell]

Originally Posted by Geoff Waddington

Support more than just MIDI -- support OSC etc.

Connecting to reaper via OSC (hence doing a separate program) supposedly will allow for the requested functionality, but when doing something "within" Reaper do you intend to access Reaper via the Tool API ? I suppose same will provide the necessary functionality, as well.

How should such a Tool access the script interpreters to "Support scripting" ? OSC2Midi has a built-in EEL interpreter and is open source.

-Michael

[G-Sun]

Very excited about this one.

I've been thinking:
What is the ultimate Control Surface-solution for Reaper/ a DAW ?
The answer depends a little on user-scenario I guess,
but multifunction touch-screen with multifunction knobs seems quite good.

Lot of knobs for most common transport/edit,
and screen-knobs changing for the chosen tasks (think toolbar-icons)

Then, the old paradigm of one fader/ch per DAW-track seems pretty useless.
Personally, one fader (selected track) is enough for most tasks.
Or, assignable faders 8/16 for typical busses.

Then, those faders should work for plugin-automation as well,
but then 2-way communication for led-labels are crucial.

It is of little use having a ton of faders/knobs if you don't know what they are assigned to/ value.

I believe track_ID is sorely missing in Reaper.

But else, most should be doable.
Generic, GUI-less plugins should be ok,
but GR-meter is maybe harder.

Just my random thoughts

[Geoff Waddington]

Thanks G-Sun !!!

Just what I'm looking for.

As far as the ultimate control surface, I've been thinking about / working on this for over 10 years now - first programming I ever did in this space was the Faderport drivers for various DAWS in 2006.

I now think the ultimate control surface is a hybrid made up of various phones/pads/fader packs/scrub jog wheels, etc. depending on the user's role at the moment - mixer, editor, post-pro, etc.

So workflow has to be the BIG number 1 with a bullet.

Otherwise why would you spend the money, time, and effort on all this mess.

You have to be able to change workflows quickly, perhaps in a way very like the layers on the live digital boards.

Most often the idea would be to remove buttons (ones that are out of context) so that you don't press them mistakenly.

For instance:

example 1: If you are not tracking, the record arm and record buttons just clutter things up, they can and should be hidden, so that they are not inadvertently pressed.

example 2: If you use an Apollo or equivalent, the input monitoring section is generally just clutter, the Apollo console takes care of that chore.

I believe track_ID is sorely missing in Reaper

I seem to recall a track GUID, I'll have to check.

Please let's keep this discussion going everyone, the product will only get better with your input.

[G-Sun]

Originally Posted by Geoff Waddington

I now think the ultimate control surface is a hybrid made up of various phones/pads/fader packs/scrub jog wheels, etc. depending on the user's role at the moment - mixer, editor, post-pro, etc.

This is pretty much what I think as well.
Maybe something along the idea of an iPad dock?

Ideally it would be a dedicated device,
but practically, a dock for a tablet may turn out much easier.

Wire/wire-less: Hm.. bought have their advantages,
but just bringing the tablet to tracking booth,
having the dock stationary, would cover most use.

One could think all text on tablet,
knobs top/bottom, buttons left/right
with the most basic transport with led-lights to right-right,
motorized fader left-left.

Stable and easy connection is important.
TouchDAW OSC -solution is difficult.
Needs something more plug n'play.

[mschnell]

Originally Posted by Geoff Waddington

Most often the idea would be to remove buttons (ones that are out of context) so that you don't press them mistakenly.

Nice idea: not only motor-faders, but motor buttons, as well, that automatically sink unreachable below the panel, and reappear when appropriate .

-Michael

[airon]

Using OSC would be neat.

It might be too big a project.

The custom plugin layouts in Klinkes Csurf were good, though Avid Icon consoles were really good at that.

If setup complexity can be reduced that would already help. More people would use it.

As for Reaper <-> OSC <-> Midi controllers,
that is a serious can of worms.

Aquisition of midi controls resources and then customisable ways of using them. For example having an action to "Control plugin 1 of currently selected track". This should present the parameter values on the predefined output capabilities of the mid device or any other for that matter.

You'd have the example I showed in my FR thread on this subject in post #1. That output command set could also be a separate OSC tablet, which I might use to show the parameters of the currently targeted olugin.

Midi knob to OSC, Reaper sends back plugin data via OSC and this magic thing sends whatever I told it to when THAT midi knob is being used.

[Geoff Waddington]

Aquisition of midi controls resources and then customisable ways of using them

Yes !!

This is the heart of the project.

The essence is as simple as this:

Controller -- MIDI, OSC, web based, etc.

Control signal -- e.g. a fader move on a controller

Feedback signal -- e.g. a button lights up on controller

Control signals cause Reaper actions - including scripts

Reaper activity sends feedback signals to controllers

(with the legalese caveat that there may also be signals that don't interact with Reaper directly but instead interact with the other known controllers in the system).

It might be too big a project.

Yup, that's why we'll do it in phases.

The phase we're in right now is the 50,000 ft view, ANY and ALL ideas more than welcomed.

It's your project folks, speak up, anything you've ever dreamed of, get involved !!

The custom plugin layouts in Klinkes Csurf were good, though Avid Icon consoles were really good at that.

Yeah, we're gonna try and take those concepts to the moon

As for Reaper <-> OSC <-> Midi controllers,
that is a serious can of worms.

Why ?

[semiquaver]

just thinking about the interaction of actions and surface - all of this might be obvious but just riffing...

for the surfaces to be maximally useful they need to be modal.

so modes need to be able to be set and indicated by toggles on the surface

we also need to be able to set what the surface controls from reaper with actions.

an action might assign the focused envelope to fader 1.

a macro could add reaeq AND open it on surface's faders for editing.

or a script might seek input from the surface: create a send and wait for a button press on a 'select' button to set the target.

a search field in a script could narrow down tracks and the results could be dynamically assigned to the surface.

in the mapping process selecting params from lists can block flow. it would be nice to be able to use text to map params - I could imagine an on-the-fly mapping window that prompts for knob 1 and accepts a dynamic search, auto selecting and advancing when there is only one result so you type 'low gain' 'low q' 'mid 1 gain' to map first 3 knobs.

Likewise a command to set jog wheel function based on last action could be interesting. say you press zoom out twice... then invoke the command and the jogwheel is set to zoom. or trim item start etc.

I think a dynamic relationship between the contexts is whats wanted.

[Netchose]

For now the best control surface support is provided by Ableton Live.
Add specific midi control surface script(ReaMidiScript ?) is IMHO the only way to go.

but like Reaper devs "are great programmers" and "make the best software"

i thing they can do even better

[airon]

Justin and Schwa might provide a better framework, but they're not going do the grunt work that a major force of users could.

Ok here goes.

Some groundwork.

Plugin parameters need to be sorted by the user in to a prioritized list.

The plugin parameters most important to the user come first. Call them Plugin Parameter A, Plugin Parameter B and so on. Past the user assignments, the rest of the parameters are just strung along. Maybe the user should be able to keep some of them out as well for those unwieldy mega beast plugins with hundreds of parameters.

This will come in handy later.

It has to stay simple. You have a bunch of resources and need to setup how they ought to be used.

At our disposal is stuff like

• MCU controllers
  which is a bunch of motorized faders, a few endless knobs, a slew of buttons and a jog wheel.
  
  Indicators include lights on some buttons and a set of scribble strips.
  
  
• Midi knob/fader boxes like the Akai Midimix, Midi Fighter Twister, with or without indicators. This also includes the Behringer X-Touch mini, which has a midi mode with two layers.
  
• Button boxes
  They all usually have indicators, like the Midi Fighter 3D or the Novation Dicer (6! colours).
  
  
• OSC Touchscreens

Now for some ways of using it. This design work is by far the hardest part I find.

• Custom Zones
  It's a specialized mode, that some folks are likely to spend most of their time in.
  
  This is akin to the Custom Zones on consoles like the Avid Icon(good, older Protools-only controller).
  
  Here is how it works:
  • A bunch of control resources are designated a custom zone
    
    
  • The user can switch this custom zone on and off. Some control resources (faders, buttons, knobs...) might still be used to select tracks and control vanilla stuff like track volume.
  
  Zone types:
  • Custom plugin control
    "Show Plugin 1 in custom zone" and so on. Each plugin can be given its own custom layout. Bank functions to page through plugins and parameter banks can be assigned too.
    
    
  • Custom Track Setup
    
    A refined way of focusing on stuff on a track. For example:
    • Send 1 Volume, Send 2 Volume, Send 3 Volume, Send 1 Mute, Send 2 Mute, Send 3 Mute
      
      
    • Plugin Zone 1 Bank Left button
    • Plugin Zone 1 Start:
      Plugin 1 Parameter A, Plugin 1 Parameter B, Plugin 1 Parameter C, Plugin 1 Parameter D, Plugin 1 Parameter E, Plugin 1 Parameter F
      Plugin Zone 1 End.
    • Plugin Zone 1 Bank Right button
      
      
    • Plugin Zone 2 Start:
    • Plugin Zone 2 Bank Left button
    • Plugin 2 Parameter A, Plugin 2 Parameter B, Plugin 2 Parameter C, Plugin 2 Parameter D, Plugin 2 Parameter E, Plugin 2 Parameter F
    • Plugin Zone 2 Bank Right button
      
      
    • Track Mute Button, Track Solo Button, Track ARM button, Track cycle monitor modes button
    
    Can you appreciate how big this can get yet ?
    
    
  • VCA Masters whose selection spill the slaves in to the zone
    
    
  • Group Members of group 1, 2, 3,etc.
  
  Access to this custom zone mode is done via actions. Each action also takes you out of the mode again when executed the second time without another Zone action having been triggered. So you hit the "Custom Track Zone" button, then hit it again to get out again. Hit the "Custom Plugin Control", then "Custom Track Zone" and then "Custom Plugin Control" again to end up in "Custom Plugin Control". You'd need to hit that again to turn the zone thing off again.
  
  
  That's a fair start and a fair warning of what this could end up being.
  
  Remember that each state also needs indicators if possible.
  
  Indicators are another thing entirely. Control knobs could be assigned default indicators. But what happens if that clashes with another default assignment. Knob Z might want to show the state of the parameter it controls as does Knob A. Who knows. Let's get there first is my moto.
  
  Let's get there.
  
  

[G-Sun]

Originally Posted by airon

Remember that each state also needs indicators if possible.

Not only indicators,
but text/labels.

With so much going on,
the knobs and buttons are useless unless you know what they are assigned to.

[Geoff Waddington]

Originally Posted by airon

At our disposal is stuff like
MCU controllers
which is a bunch of motorized faders, a few endless knobs, a slew of buttons and a jog wheel.

Indicators include lights on some buttons and a set of scribble strips.

Midi knob/fader boxes like the Akai Midimix, Midi Fighter Twister, with or without indicators. This also includes the Behringer X-Touch mini, which has a midi mode with two layers.
Button boxes
They all usually have indicators, like the Midi Fighter 3D or the Novation Dicer (6! colours).

OSC Touchscreens

Yes, but you can view these as simply 2 kinds of input:
Switches - binary
Encoders - range - fader, endless knobs, jog wheels, etc.

and 2 kinds of output:
Lights - binary
Displays - scribble strips, meters, endless knob position ring leds, etc.

Originally Posted by airon

Now for some ways of using it.

Custom Zones
It's a specialized mode, that some folks are likely to spend most of their time in.

This is akin to the Custom Zones on consoles like the Avid Icon(good, older Protools-only controller).

Here is how it works:
A bunch of control resources are designated a custom zone

The user can switch this custom zone on and off. Some control resources (faders, buttons, knobs...) might still be used to select tracks and control vanilla stuff like track volume.

Zone types:
Custom plugin control
"Show Plugin 1 in custom zone" and so on. Each plugin can be given its own custom layout. Bank functions to page through plugins and parameter banks can be assigned too.

Custom Track Setup

A refined way of focusing on stuff on a track. For example:
Send 1 Volume, Send 2 Volume, Send 3 Volume, Send 1 Mute, Send 2 Mute, Send 3 Mute

Plugin Zone 1 Bank Left button
Plugin Zone 1 Start:
Plugin 1 Parameter A, Plugin 1 Parameter B, Plugin 1 Parameter C, Plugin 1 Parameter D, Plugin 1 Parameter E, Plugin 1 Parameter F
Plugin Zone 1 End.
Plugin Zone 1 Bank Right button

Plugin Zone 2 Start:
Plugin Zone 2 Bank Left button
Plugin 2 Parameter A, Plugin 2 Parameter B, Plugin 2 Parameter C, Plugin 2 Parameter D, Plugin 2 Parameter E, Plugin 2 Parameter F
Plugin Zone 2 Bank Right button

Track Mute Button, Track Solo Button, Track ARM button, Track cycle monitor modes button

Can you appreciate how big this can get yet ?

VCA Masters whose selection spill the slaves in to the zone

Group Members of group 1, 2, 3,etc.

What you're talking about could be equated to the "layers" concept on digital live boards (both audio and lighting);

It will allow cool tricks:
in PT plugins are slot based
in Reaper plugins "snug up" when you remove one, there are no blank spaces.

This software has to allow for setting up a layer that consists of any desired plugin, based on a per track choice.

An example
Track 1 EQ is in slot 1
Track 2 EQ is in slot 4
Track 3 EQ is in slot 2
Track 4 EQ is in slot 3

So, in setting up an "EQ" layer, you would assign accordingly for each track.

That gives you even more flexibility than PT, and allows for the benefits of a slot based approach in Reaper.

The cost of all of this flexibility is obvious, more setup time, because of the extra required decisions in the setup.

As I said a few posts back the tech is non-trivial, but pales in comparison to the UI work needed for a successful solution.

Lots of matrix type tools, easy graphic ways to represent numerous surfaces that make up your individual "aggregate" setup, e.g iPhone, iPad, Avid Artist Mix, Faderport, all require a LOT of UI thought.

Don't forget, some settings will be global, some local to each project, just to throw in some more spice.

Once again it is the UI that is the most critical component.

Originally Posted by G-Sun

Not only indicators,
but text/labels.

With so much going on,
the knobs and buttons are useless unless you know what they are assigned to.

Absolutely !!

[G-Sun]

Do we need participation of a hardware developer and Cockos?

[airon]

We'll see G-Sun.

Look at the work for the LBX Strip creator here: http://forum.cockos.com/showthread.php?t=182233

This might be exactly what we need. He could probably help out with a decent framework. Writing THAT stuff in Lua could be just the ticket to take advantage of the enormous talent in this forum.

Just take a look at the last post on page 36(!!). Stuff people are coming up with.

With simple shapes or whatever people want to use,the visualization and configuration could be close to being solved on a technical level already.

[airon]

Btw, I meant the LBX strip project adapted for this projects needs would be for configuration only.

[Geoff Waddington]

Made the thread title more reasonable now that the election is over.

[airon]

How do want to start on this ?

Tackle the MCU as the big test case might just be a good place to start. Many folks have such devices.

The way Klinkes csurf gave us all the extra layers could be the starting point.

If midi gear is adressed as control-enabled midi devices, the MCU would have to live like this too. On the other hand that gives you more flexibility in putting your personal control setup together.

Several type of presets could come in to play.
Device resource presets that let users skip over the aquisition of midi-learn-collected resources.
The composition of these resources in to a control setup is another and it likely encompass the device presets.

Layers such as one controls a currently selected plugin could be filled with device presets, whose control resources get auto-assigned according to a list of preferred parameters for each plugin.

[Geoff Waddington]

Originally Posted by airon

How do want to start on this ?

Well, things are getting more interesting - http://forum.cockos.com/showthread.php?t=184572

One vision in one work context, my own coincidentally of how this whole thing works says that it should be easy to incorporate a phone and/or pad into the system.

For instance a Tranzport/Faderport view for a phone and a VST view for a pad.

Since the web interface is currently under development, I want to jump in early on this, the ground floor so to speak

[airon]

We could start with device resource acquisition.

Resource types.

First on there is the simplest. Midi controllers in all its forms (absolute, toggle, toggle-through-number-of-states,relative1-3)

But how do you capture OSC resources ?
I'm inexperienced with OSC though.

Presets of resources should be sharable, perhaps via clipboard similar to what ValhallaDSP plugins do or file exchange. Paste/load a preset and ask which device it is referring to, and we have a bunch of new resources ready for use.


Once we have resource acquisition, we can turn to layers and zones. Zones can have their layers switched with actions, which in turn can be triggered from anywhere. That'll be the bigger GUI challenge. Representing the GUI resources, perhaps creating a simplistic layout for users to better remember stuff, and then creating zones from them.

What do you think ?

[Geoff Waddington]

Originally Posted by airon

We could start with device resource acquisition.

Resource types.

First on there is the simplest. Midi controllers in all its forms (absolute, toggle, toggle-through-number-of-states,relative1-3)

But how do you capture OSC resources ?
I'm inexperienced with OSC though.

Presets of resources should be sharable, perhaps via clipboard similar to what ValhallaDSP plugins do or file exchange. Paste/load a preset and ask which device it is referring to, and we have a bunch of new resources ready for use.


Once we have resource acquisition, we can turn to layers and zones. Zones can have their layers switched with actions, which in turn can be triggered from anywhere. That'll be the bigger GUI challenge. Representing the GUI resources, perhaps creating a simplistic layout for users to better remember stuff, and then creating zones from them.

What do you think ?

I was fortunate in having done an iOS app last year.

Learned a hell of a lot about simplicity, pragmatism, taste, etc.

The part that applies to this project is the part that says "The best way to simplify configuration is to eliminate it".

To that end I have started a little POC (proof of concept) that will test some of these ideas.

I'm going to write an iPad app that has an LA2A compressor, complete with multitouch controls.

This app will control (via OSC I think right now) the VST plugin in Reaper.

The goal is to have zero setup.

OSC Gateway apps run on both the host computer and the iPad and discover each other -- zero-config.

After we have reduced the setup/config to as much as possible, we then will have to tackle all the mapping, layering, zoning, etc.

This will likely be an ongoing project with multiple releases of multiple apps on multiple platforms over a number of years.

[G-Sun]

Originally Posted by Geoff Waddington

"The best way to simplify configuration is to eliminate it".

That's Reaper-blasphemy

[mccrabney]

I was fortunate in having done an iOS app last year.

Learned a hell of a lot about simplicity, pragmatism, taste, etc.

The part that applies to this project is the part that says "The best way to simplify configuration is to eliminate it".

shudder x3

[Pinecone]

the coloured scribble strips activated in the Behringer X-touch without it having to be network connected?

[Geoff Waddington]

Originally Posted by G-Sun

That's Reaper-blasphemy

Originally Posted by mccrabney

shudder x3

Haha Relax, there will be plenty of room for configuration, don't worry, I'm talking about removing the tedious, repetitive, no gain for the added complexity, stuff

Can't believe I missed this but it's been out for a couple of months now:
https://neyrinck.com/products/v-control-pro-bundle/

Scroll down a bit to get the idea.

So the no config part we are talking about (and what they have apparently implemented as well) is the automatic discovery of compatible control surfaces.

What I have in mind is something like the V Control Pro concept on steroids, with typical Reaper configurability.

I would encourage any and everyone to download the free version or the trial version and let us know what you liked and didn't like about it.

Any feedback on the V Control good or bad can only make this project turn out better.

[ivansc]

Geoff - this thread actually has me excited about the future prospects re reaper and remote control devices.

Having been through th BCF Korg nano etc route, I had pretty much decided that what I had was as good as it was likely to get, coupled with touch OSC.

Can't wait to see how this pans out. Not sure I really have time but I plan on D/Ling V control and seeing what what....

[Geoff Waddington]

Just realized something, at least I think I did

To all those who recorded analog, you likely remember ye control rooms of olde, where the center of command and control was the console.

You typically had a tape remote called something like autolocator to easily reach tape controls whilst seated at the console.

I think we would be making a mistake to follow that paradigm, indeed I think that's part of the reason control surfaces haven't been as well received as they might have been.

I'm suggesting we have to assign our notion of center of command and control to the DAW itself, not the external console controllers.

Seems simple and obvious, but changing my perspective thusly is causing me to think differently about this project.

A bit subtle, does anyone else agree, or does it seem like I'm just blowing smoke ?

[semiquaver]

Totally agree. Physical controls are best seen as an extension of the DAW UI...

[airon]

I'm certainly in favour of keeping all the intelligence in the DAW, and relegating all external controller hardware to being what they are, dumb-fuck devices that send data the user enters and have blinking lights.

OSC tablet apps are different. They can be controllers but have to be designed on the pad, not the DAW. HOwever if you use the them to be a blinking light display, it will work too.

If that's what you meant, I'm all +1.

[Geoff Waddington]

Originally Posted by airon

I'm certainly in favour of keeping all the intelligence in the DAW, and relegating all external controller hardware to being what they are, dumb-fuck devices that send data the user enters and have blinking lights.

OSC tablet apps are different. They can be controllers but have to be designed on the pad, not the DAW. HOwever if you use the them to be a blinking light display, it will work too.

If that's what you meant, I'm all +1.

Well i think you've cut to the chase here, yes, it is the OSC pad devices I'm considering, I think we're on the same page, sort of very smart but still glorified blinking light / touch input displays.

[maranite]

Bitwig supports event-based javascript along with a "cursor based object model" (read: context sensetive API).

This has allowed me to easily integrate my Arturia keylab 88 in ways that I'm simply unable to achieve in Reaper.

A simple "lua script" control surface plugin for reaper would be a great start. An event based api, where the script could listen for actions in reaper would be super.

I prefer using reaper to bitwig, but the bitwig boys definitely got it right on their controller api. Hopefully something similar will be developed for reaper?

[ivansc]

Although I currently use a pair of nanokontrols and am happy with how they do what I bought them for, I also use TouchOSC for remote control of reaper & would LOVE to see easier/better integrsation at any level with reaper.

Mind you fwiw the ACt IMPLEMENTATION IN sONAR IS NO BETTER THAN WHAT WE CURRENTLY HAVE ON rEAPER... Aw shit! arthritis again