Modern MIDI Controller Support

Hermu
ACT was created 2007, but now we have 2015 and todays MIDI controllers have more functionality than before.

As cars have not learned how to fly, MIDI controllers still just send/receive MIDI
 
ACT is using VSTi specification to control parameters (all other "new" technology use the very same approach).
 

Cakewalk Generic Surface is also outdated and has a crazy handling.

I do not see something which can "outdate" in this particual plug-in, and its handling is hard to beat in simplicity.
 

What we need is a modern MIDI Controller Support for actual Hardware with a user friendly GUI.
This is a realy important feature, because without a good MIDI Controller Support the best DAW is uninteresting

CW goes the "Touch" way.
 
Some time ago hardware producers had dedicated support for Sonar. But they do not do this now. And so, nether CW not Controllers manufacturers agree the feature is important.
 
While a bit buggy, Sonar has Open Source and more or less complete Controller Support. So in case someone producing "actual Hardware" (in fact selling 20 years old devices with face lifting, at most with 10$ worse LCD display addition) want support Sonar, they can.

Hermu
Sorry, but compared with other actual DAWs on market has Cakewalk a poor MIDI controller support and i want to keep struggeling with this software and i am no ready to buy this Software anymore.

Any example what Cakewalk does not provide for MIDI controller and other "actual" DAWs do?
That will be constructive.
 
If you are speaking about some particular device, which one?
 
Please note in case producer of some device does not deliver Sonar plug-in as they do for other DAWs, that is a question you can ask the producer of the device.
 
It is like asking General Motors why some "modern car radio XYZ" does not fit into the car with proposal to change the car design and claiming you will not buy any cars from them till that happened
 
Ready to accept "car radio converter"? See my signature. You can cooperate any controller with Sonar. But near everyone asking similar questions is this forum "has no time" for that and ask for "boxed" support. So again, if you want see something inside the box, ask the producer of this box.

The best example I can give for the need to improve CS support in Cakewalk products is the fact that in other DAWs, I can get the proper response to encoders, sliders and buttons setup from scratch in a reasonable amount of time.
 
However, trying to get things working in Sonar is, for me, like trying to operate a spacecraft with everything labeled in a language I don't understand.
 
I think the fact that "we" have to rely on the kindness and generosity of a third party to get things working speaks all that needs to be said on the subject.
 
How would I prioritize this?  I honestly don't know.  There is a lot to be done all around.

azslow3
Well, so you do not want some particular device does something special with Sonar. I could help with that.
 
But you are asking Cakewalk (only) to do some "Magic", so any device is automatically controlling "right things". I can not help with that (and I guess no one can).
 
About spacecraft language and either it is possible to avoid it. Just 2 real life examples:
1) Faderport buttons send not the same MIDI signals as it expects to lite corresponding LEDs. Even worse, the fader expect feedback value in lower 10bits of 14bit field while sending the value in upper 10bits of 14bit field.
2) Some encoders send 1 on turn left and 127 on turn right, other send (1...10) on turn right and (64...74) on turn left (speed dependent).
How to call corresponding options in DAW Surface Configuration without using "special" language?
 

Hermu

azslow3
Any example what Cakewalk does not provide for MIDI controller and other "actual" DAWs do?
That will be constructive.

Ableton, Bitwig Studio, Cubase, Reason, Studio One which supports also plug&play Controller device recognize and it's also possible to write or adapt your own config html file for not supported hardware controllers.
that's felxiblity and it's not realy important to have a Hardware producer support or not.

Cakewalk support plug&play MIDI device recognition, fully configurable ACT MIDI and Generic Surface plug-ins, "Remote control" MIDI learn and Open Source MIT Licensed API with complete source code for several devices. In case you like "friendly" way to edit XML files, you can configure my plug-in to do whatever you like (on the level not available in any other DAW, prove me wrong if you can).

You are obviously too close to this one.  There are standards and there are implementations.  The standards should be supported and the implementation should make standard support AND also make customized actions/ranges/etc. simple.
 
 

I would really, really appreciate if CS support would be given higher priority, but every few weeks we have similar threads and if you follow them, you realize this will not happen because ...

1. hardly anyone in the Sonar world seems to be using it - it is always the same few people who reply/help when CS issue appear so you can estimate the rather (low) number of users actively driving Sonar via CS
2. more people seem to work with touch (despite being seriouly limited compared to CS) and this is where Cake puts (some) money
3. all CS source code has been published and released into the public domain, hence no more work from Cake on any of the legacy CS dll (which basically means no further improvements on any CS integration)
4. worst of all, even ACT, which is controller independent and still advertised as one of Sonars strong points for "seamless" integration is seriously broken since X3 and getting worse now with Platinum ...

any more points needed ... ???
sad but true.
 
personally I'm still on the vs-700 and it works as it did since X1d (which is good) and I definitely don't want that to be broken ... but I can't expect any fixes ... I even embarked on trying to compile the source code myself and see if I can figure out some improvements myself ... however that would cost me about 500€ to update my dated dev environment and so I put that on hold until I have more time/money/motivation (which just may never happen)

That is already constructive

Hermu
1. i'm using a Mackie Control compatible MIDI device, and it has worked as VS-700 device, but now with SONAR Platinum VS-700 is not longer supported and Sonars Mackie Control didn't work with them. Thank's SONAR Platinum, i have now lost my MIDI Controller support, which i have used since X1.

VS-700 plug-in is still the same since X1. Unfortunately, there was "packaging error". Download Control Surface plug-in for VS-700 separately (do not have the link in hands, but there was several discussions about this issue).
 

2. if i want to use my Mackie Control compatible MIDI device, i must configure this device twice, because i have 9 faders - 8 tracks and 1 master. Transport functions have a different behaviour in ACT and Cakewalk Generic Suface.
3. in ACT its not possible to configure Mute, Solo and Record Buttons, so i have to use Cakewalk Generic Surface. To need of 2 configurations for 1 controller is not realy comfortable and if you have to use more Controllers, it's realy hard to understand the complexity. ACT can not compensate Mackie Control support.

That was the reason I have made my plug-in.
 

what i want:
1. one config file for one MIDI controller in XML format, which should contain all my MIDI controller elemens - faders, buttons. as example name="fader1", type="fader", MIDI="B0 32", min=0, max=127. A xml config file would allow to create easy a configuration for non supported MIDI controllers and no one should learn any specific language.

Do you assume that XML is not "specific language" for musicians? Also to make something more then one to one mapping, DTD for such XML is going to be "true alien language" for most users.
 

2. for each plugin or mixer, a xml file with controller assignements, based on MIDI controller config file could be created with ACT midi controller assignements.

They have it in ACT model. But is has several bugs. So it is more bug fix request then feature request.
 

3. a clear and easy to handle ACT MIDI controller config GUI for Mixer and Transport, Mixer should also support Buttons for Mute, Solo, Record, etc.
4. Only one MIDI controller config should be required - Cakewalk Generic Surface or ACT

Another reason why I have written my plug-in.
 

5. make Mackie Control support compatible with more third party Mackie compatible devices, because my Mackie Control device works with all other DAWs without any problems.

MCU implementation of Sonar MCU plug-in follows open specification from Mackie. It can be "all other DAWs" and your device do not care about original specification, but that is not the reason for CW to follow.
 
In fact usual problem is that "compatible devices" do not implement Mackie challenge/response. I do not know why, may be just license issue... But they are "Mackie incompatible" by definition then, does not matter what they claim.
 

@azslow3: please have a look, how other popular DAWs have realised MIDI controller support and then we should talk constructive about

I do not have "all other DAWs". I had a look at Ableton way and I was not fascinated.

FreeFlyBertl
as regards XML ... I hated it from the first time I saw it and sadly this beast is on our backs almost everywhere these days ... I used to develop software for years, but still don't get the point of using xml for user editable config files (IMHO - if you allow someone to fiddle with it the old *.ini file type approach is much more intuitive and maintainble, if you don't want users to fiddle, go make it binary) ... well, I know groups of parameters are difficult to do *.ini style, but nothing beats table style representation of parameters, so that would be the route to go for any kind of parameter assignment (copy & paste functionality to spreadsheet programs of course must be considered)

XML files should be clear structured and with a XML editor (Programmer's Notepad) easy to read.
But these XML files should only be modifyed from hardware manufacturers or qualified users with XML knowlege.
 

FreeFlyBertl
the current state of the ACT system is a shame ...

• you can ACT learn and IF you get it to map properly (which is not certain because parameters are pre-mapped and thus ACT itself sometimes gets confused and does not follow your assignment), the ACT assignment is all screwed up when you exit Sonar an start Sonar again
• ACT settings are apparently only written when you exit Sonar ... if it crashes before, ACT changes are gone (which at least doesn't happen too often these days)
• the garbled ACT xml output Sonar writes, you can't even fix manually because it's XML written in a user-unfriendly way i.e. line breaks missing and all parameters just one after the other ... while this supposedy is no problem due to XML specs, it makes editing impossible and potentially causes also some readback errors ...

My observations:
 
There are 2 files where ACT mapping is saved: genericpluginparams.xml and sonaract.xml. The first one is "generic" and the second one is "per Control Surface type" (suppose to be).
 
When you ACT learn something, the information is written into both files on Sonar exit. As explained on my site, ACT learning is "safe" for current project only in case you do it inside "ACT" Tab of my plug-in. So restart Sonar (or at least reload project) is "a must" action when remapping ACT in most cases.
 
But when you restart Sonar, it looks like it "does not like" what it has just written into sonaract.xml. It ignores that information and on next exit (in case you have not modified ACT for the plug-in again) the information is REMOVED from sonaract.xml. While it is a bug, that way we have to modify genericpluginparams.xml only. That file is more user friendly, I have no problem editing it with Windows Notepad. The order of options in that file is the order used to assign ACT, so if "knob" "trim" is mentioned as the first and "knob" "scale" as the second, "trim" will be ACT Knob 1 and "scale" will be ACT Knob 2. Unfortunately, when you ACT learn, last learned parameter appears as the first in the list. That is why you see "messed" configuration.
 
By Sonar design it was foreseen that sonaract.xml is used for the mapping. It has information that "Generic Surface ACT Knob 1" is "scale" for example, so the ORDER of parameters inside both files should not be important.
But as I have mentioned, that description is ignored (most probable not saved correctly) and Sonar recreates the mapping "from scratch", using the ORDER inside genericpluginparams.xml.
 
So, for Hermu:
if you like XML manual editing and want per surface mapping of ACT parameters, Sonar support that! The mapping created that way is persistent, also for (otherwise buggy at the moment) VST3.
 
In the beginning of genericglupinparams.xml you can specify how Sonar should create initial mapping for unknown VSTs.