So some time ago I’ve talked to José about the possibility to build a Zynthian Controller- a ‘lite’ version of Zynthian that would only be used to control software running elsewhere. It could be very useful for studio usage, generic MIDI controllers are generally not well suited for plugin control.
We originally spoke about using an Arduino-like board and USB connection for maximum simplicity but since it has occurred to me that it could be easier done using a singleboard (like the RasPi) connected via network. Beaglebone for example does networking over USB.
If I’m not mistaken, Zynthian uses Carla as its plugin host, there is a remote application for Carla (Carla control). Could that be used for this task?
I think the decission of hardware should not be the point. Using Artduino/Raspi/Beagle/ESP/… should be the choice after looking at the protocol and how to get the data towards the software.
Currently Fernando has used Carla as one of several sound engines. But Carla maybe not be further developed as his maintainer works for MOD devices (I talked to him last Wednesday) and they are creating the successor of Carla (or InGen): MOD-UI.
I think the best way to connect controllers to Zynthian would be a middleware that speaks one (or more) control protocols for connecting external controllers and maps them internal to control the sound engine. For your idea (Raspi+Ethernet) OSC maybe a good solution. The middleware has to take the incoming data and convert it to something the internal engine understands - so for the current state this could be MIDI or OSC.
I am currently porting MOD-UI/MOD-Host to the Raspi. Works nice. MOD-UI has a feature (MIDI-learn) to connect any MIDI-Controller to a value of the a plugin. I will try to take Fernandos zyncoder-library (which is capable of speaking MIDI for the encoders towards jack) and write a (simple?) program to connect them to ports of the plugins. For your idea the way maybe the same: your controllers are sending OSC? So extend the program to map OSC messages to MIDI controller data.
the hardware of course is not the main point to discuss, there is a plethora of embedded devices, all of which have their positives and negatives (for example I dislike the RasPi because it won’t boot without a proprietary blob). For a bidirectional controller OSC is probably the way to go.
It’s too bad about Carla possibly getting discontinued, the MOD system has always felt a bit too user-experience-y and that often makes it less efficient to get stuff done. Also as opposed to Carla it’s sluggish on my system. However both MOD and Zynthian are designed for live usage and a well optimised MOD port could really shine combined with a Zynthian box…
Good morning.
Due to my set-up design it will be very interesting to manage full MIDI implementation: from classic SySex to CC or NRPN. (After this some coverter box from MIDI to DMX).
But, it will be possible to manage GPI ports (General Purpose Interface) or GPO ports (General Purpose Output)?
Sorry. I’m not programmer, only Sound Engineer & Composer.
Due to my knowledge limitations of this plarform it will be possible to develop some kind of interface for dummy user like me?
sorry, I have to ask back, because I don’t understand exactly what you want to do:
The Raspi has GPIO-Ports - you can configure them to input or output and with shell scripts, programs or kernel drivers you can use them from simple “LED on / LED off” up to DMX. But most of the GPIO pins (or all) are currently used for encoders, TFT, and MIDI. Do you mean those GPIO-ports?
There are other possibilities:
I added to my Zynthian a MIDI-Lightshow (Zynthian-MIDI-Lightshow-Demo). This is Raspi-external hardware (an Arduino with MIDI-In, WS2812B LED stripe for light and a program which recognizes MIDI notes/chords and creates coloured light depending on keys/chords).
For DMX on GPIO pins you definitly need a kernel driver. There are really hard timing dependencies… or you use a USB->DMX adapter.
Ok. Thanks. GPIO questions answered and understood. (The how to… is another song form me
MIDI to DMX with a converter box will be ok to arrive to the light desk or so…
And what about the full MIDI implementation (SySex, CC & NRPN) to control external synths o controllers or a BCR 2000 controlling many parameters or DeXter or the ZynAddSubFX?
Currently, the MIDI-IN port on zynthian is limited by the ttymidi/mod-ttymidi implementation, that supports CC and NRPN, but not SysEx. In the other hand, MIDI-USB supports CC, NRPN and SysEx.
Regarding the engines, ZynAddSubFX supports CC and NRPN, but i think you can only use NRPN for FX parameters. Synthesis parameters must be mapped to CC (this has to be confirmed because ZASFX developpers have improved the MIDI control subsystem recently).
And so on. Every engine/plugin has his own MIDI implementation.
For MOD-UI you can use any connected MIDI controller and the system “learns” which knob it has to use for which paameter. I think only CC - but I am not sure.
Regards, Holger
P.S.: You guys are getting me down. Now I also need a BCR2000 with Zaquencer…
ttymidi or mod-ttymidi is the MIDI “driver” in user-space. In fact the program listens on the Raspi-UART (serial) interface and creates jack (audio server) conform MIDI events. This software does not understand SysEx…
The “mod” at the beginning of the name means that the MOD team has extended and patched the original version…
Not sure I’m any better to explain this but I too have been learning the Linux way of things.
So on the RPi there is a UART (hardware to shift bits in and out) that can be used, as on most other PCs. By default, it is used for a console port ( to work with the computer OS via a terminal). It can also be used by user apps if the OS ‘console’ support is disabled. The second thing to understand is, like most PC serial ports, it doesn’t support the Midi serial speed by default. With some edits to the system it can be made to send and receive at the Midi baud of 31,250; but even doing that, the uart will still be seen as a common serial port, not a midi interface by the OS.
This is where TTYMidi fills the gap, it’s a program that talks to the UART and transferred traffic to a ‘software’ midi interface that OS and other software can see. The Sysex limitation is due to the program, so to overcome this would require a rewrite.
As noted, a class compliant USB to Midi external device is detected and mounted by the OS without fuss
Yogi
