I plan to buy some Steinberg CMC control surfaces.
One nice box is the transport one. I have read in the Ardour’s documentation there is a file to write to map the midi codes received into Ardour’s commands. The commands are for instance record start or record stop. A surface control contains buttons that send midi codes when I press or when I release. If I press again, the same code is sent. How to handle that?
Another nice box is the channel box. it contains one fader, some buttons and a rotative button to change the active channel. How to program it? I mean the same solo button or the same fader apply to different buses or tracks depending which one is active. How Ardour displays on the screen which one is active?
Regards
Patrick
PS it can be nice if the input dump feature would be able to dump into the console while filtering a given code some boxes sends always the beat even if it is not activated. I am thinking of a particular drum sound module. Don’t worry I only have to restart Ardour with a command like Ardour2 2>&1 | grep -x thecodetogetridof
PS2 CMC works with Linux as long as the vendor and device ids are added to the sound/usb/usbquirk.h file
You are confusing Ardour2 and Ardour3’s surface implementation.
Ardour2 only has Generic MIDI Learn for Generic MIDI Control Surfaces. Once you set up a session to use Generic MIDI, it is recommended to make a template from the session so you don’t have to repeat every time.
Ardour3 on the other hand you can write the XML files you are probably thinking of for each surface.
In as far as the problems in particular you are having I would suggest getting on IRC (Help>Chat) and speaking with us there about them. It will be MUCH faster than trying to troubleshoot them via the forums.
XML: That’s the drawback with google, I searched for midi mapping site:ardour.org and I jumped on a documentation page that related to Ardour3 and not the late versions of ardour 2. It’s true the documentation talk about Ardour 2 as the past.
In fact the problem is not the usage of the Ardour’s learning but the non standard things by Steinberg. Since Steinberg is owned by Yamaha, keyboards integrated circuits has been used.
pressing a key sends a note on with velocity 127
releasing a key send a note off with velocity 0
the fader on the CH box is a pitch
there are 2 categories of buttons: the whose light on (and off) themselves when they are pressed, the whose light on or off when they received note on (via the feed back)
the fader/pitch sends a note on (V 0 or V 127) before and after the finger touch it.
But the codes of the CH and TP boxes does not overlap except the shift key. It is nice for A2 which does not support more than one control, and nice for A3 to not have to set many drivers as long as only one box of each is bough.
Designing an integrated circuit costs at least 1 million euros, and each masks set costs at least 100K euros. Then nobody have a budget for that anymore only for one “private” item. They can not design boxes using fpga as that would be too expensive.
Then yesterday evening I bought one to try.
The box is not identifyed as a midi box but is fully recognized as a usb item with ids 0499:1060
0499 is Yamaha, that mean they bought the circuits to Yamaha which provides many midi items
… and the quirks file in the Linux kernel contains already a lot of Yamaha items (perhaps all of them!!!)
Using the Ardour’s dumping system:
buttons return a note on with its note and with a “volume” 127 and a note off with its note with a “volume” 0
the control returns its control id and a code to tell I am turning clockwise or counterclockwise
the fader returns its position, but strangely no id (or Ardour does not display it)
The note ids are not modifiable and look like very random (e.g. a 8 after a 96, other keys are 43…). Then I bet each of the 127 midi note code are never reused from a version to another. Then if more than one box are bought (but different versions) all the midi can be merged without conflicts
Yes but you should be able to plug in multiple identical boxes as well. And since these all show up as separate USB MIDI devices after you modify the quirks file, conflicts don’t need to be worried about as I don’t believe i remember daisy chaining being possible with those. It does mean a slight rethink of how MIDI control is done in Ardour, even in A3 actually, so I need to catch Paul about that one as I think using multiple of those could cause some issues in flexibility of control when trying to get multiple midi devices to each control different tracks or aspects of the tracks.
Which CMC box did you purchase? From your description it sounds like it may be the CMC-CH? I may be willing to pick up a couple myself to implement these and replace my Mackie unit with something a bit more compact and usable with Ardour, etc.
By the way, for the record it may be best for you to ‘cat’ the MIDI device node on Linux (I am assuming that is what you are on) to see the RAW MIDI stream coming in and diagnose commands sent via that instead of by Ardour’s trace mechanism, which while nice I find looking at the raw MIDI preferable in cases where I am looking to implement a protocol.
Indeed I bough the CH which is the channel. This afternoon I also bough the transport one.
The transport need another entry in the quirks as the model is 1061 rather than 1060! However, as I bet, the midi codes does not overlap (hope it does not between all the 6 boxes) except the 70 which is the shift key.
The problem I am on now is to enter the mapping to Ardour. I drawn on paper the codes and the keys (don’t surprised Steinberg used the midi codes randomly). If I try the self learning I have 2 problems
In the transport, keys are executed but also they toggle the global record button.
In the channels, I tried to learn on the selected channel (while using the shift E command to display it on the left) but Ardour remember the target channel rather than the principle to act on the active one. I understood in the XML file you called that /route/xxx, regardless it is a bus or a track(sorry for my previous message)
Also in the channels, the mute is set to on when I press but not reset when I press again
Are you expecting surfaces control that send on or off when buttons are toggled? CMC devices send note on and off when you press or release.
I am trying the xml file (I always prefer config files to mouse configuration), nothing happened. I placed the file in the folder I am opening Ardour, correct? You wrote in the documentation to double click on the generic midi of the surface control tab of the preferences, I don’t have that. The preferences is the menu item in the windows menu item, correct? In the preferences, I have a midi tab but no SC tab. In the option menu -> control surface item, I can see the generic midi but it is not double clickable.
I am using the 2.8.12 on Linux kernel 2.6.36 and jackd 1.9.8
Using more than one box of the same version is possible, indeed, as they appear separately in jack, but Ardour has only one control entry node and probably one active surface control handler at a time.
Since I needed some minimal working ASAP, I wrote a software that places a midi node (input and output) with 2 ports each (control and feedback) and converts all the weird things.
I sacrificed 6 buttons as the route (track or bus) selection. According with it, midi codes are converted. The major drawback is the state of the fader and the rec/solo/mute buttons is stored in my software, then I can not change that on the computer.
Does some guru of the midi part of Ardour ready for an IRC chat to help me to port my software to A2? When (I am GMT+1 time)?
Unfortunately I can not yet use A3 as I have the buffer connection problem (that crashes Jack 2), and I can not use jack 1 as I am running a multi core machine and I am using Ffado.
Unfortunately I can not yet use A3 as I have the buffer connection problem (that crashes Jack 2), and I can not use jack 1 as I am running a multi core machine and I am using Ffado.
This is deeply confused. I suggest you carefully read http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2 which will clear you of the misconception that your multicore machine is some sort of issue. Jack1 supports FFADO just like Jack2. As for the buffer connection problem, I'm not clear which problem you are referring to. You don't mention any bug report IDs or a version of Jack2.
As Seablade noted, A2 is now feature frozen and no new features will be incorporated into the program.
@Paul I have a problem and I searched using (once more) Google. I found somebody with the same problem: comments.gmane.org/gmane.comp.audio.ardour.user/11104
You wrote you are testing with jack1 and the other should work. It does not work for me with jack 1.9.8 gcc 4.6.2 libsigc++ 2.2.10 glibc 2.14.1 kernel 2.6.36 regardless -S or not.
@Paul & @Seablade The idea was for me to work on A2 in the meantime in order to finish to discover all the bad things of the CMC (see above). By making a full running solution (even if it is never released) we can check if the XML system supports everything and if so add some support (at least the fader as pitch but also some led feedback)
To chat using IRC via Pidgin rather than Ardour (more easy to left windows behind) which address should I type?
Hmm new features in A2 are unlikely to be accepted at this point as it is in a feature freeze at this point. A3 hopefully won’t be to much longer in being released and your efforts would be much better aimed to that instead.
All that being said jump on IRC when you have time and just ask your questions, then leave the window open(In the background or minimized if needed) to see if you get an answer.
After some recompilation of Jack1 and jack2 (that indeed does not change anything) but also the Linux kernel, I found a work around to make A3 running: compile without the SMP but while keeping the highmem 64G. The problem may not be the one stated aboce as I still have many jack buffer connections errors but A3 starts. Since the SMP is for me useful only for Spice, I can leave with this dual boot.
I can see in A3 the Mackie driver is still here. What is the development strategy? re-include the Mackie driver into the XML system or use the XML system only for the simple surfaces?
I wrote a minimum XML file for the TP and the CH box. I have problems with the CH as the channel does not select. I need some not yet supported features for the TP and the CH.
What is suggested? Writing some patches to improve the support of the XML system or writing a driver in the Mackie style?
How A3 will manage the case people buy more than one box? I think a generic solution can be written for the 6 CMC boxes as long no box is bought twice. In this case, we should be able to connect boxes to different instances of the XML system.
I can see in A3 the Mackie driver is still here. What is the development strategy? re-include the Mackie driver into the XML system or use the XML system only for the simple surfaces?
The majority of the Logic Protocol functionality (Banking, etc.) is now possible using the generic MIDI control surface support, so the goal is to reduce redundancy by incorporating much of it in that manner. However some of it will still need some custom code, when someone has that time is still anyone’s guess as right now my time is exceedingly limited.
What is suggested? Writing some patches to improve the support of the XML system or writing a driver in the Mackie style?
Most likely improve the XML, but this is a discussion that should happen over IRC.
How A3 will manage the case people buy more than one box? I think a generic solution can be written for the 6 CMC boxes as long no box is bought twice. In this case, we should be able to connect boxes to different instances of the XML system.