Yesss, a proper Studio with Zynthian and Rosegarden

Using Zynthian
1

After a lot of feedback, critical sounds :slight_smile: and a lot of work finally Zynthian power in my grasp.

Let’s recap, for the sharing is caring sake of argument.

As you know I built the Zynthian hardware in a custom made box. I turned out I needed a heatsink, which is now connected to an outside heatsink to dissipate and transfer the heat.

Next connecting the equipment. My setup now is as follows

image
image1328×402 60.5 KB

Use a Novation Launchkey 61 keyboard. What I like about the keyboard is the 8 knobs, 9 sliders and 9 knobs. Futhermore it has buttons for looping, recording, starting, stopping and ffwd/rwnd.

Since the keyboard spits out midi commands that do not correspond to rosegarden control, qmidiroute was needed to translate the messages. We needed to translate no less than 18 midi messages to have proper control.

With the script generateBanks.sh at https://github.com/vlietland/RosegardenBankGeneration, cloned in Zynthian you can generate the rosegarden generated.rg file that contains all the ZY and FS banks and instruments in Zynthian. Just try it with the latest pushed version. It works great. Was thinking to create a video of it. Really nice to see a picked bank and Program in Rosegarden, auto changing in Zynthian. Love it !

As you know I needed the latest Zynthian midi_bank_change fork, due to the missing MSB/LSB functionality. Currently I use my code version: https://github.com/vlietland/zynthian-ui, but @Jose fixed the code as well, though did not test the latest yet, since the Friday version did not yet work for us.

Midi channel 16 control, e.g. to remotely load the corresponding Snapshot is not used yet. In fact I am afraid that I will find a lot of new bugs :slight_smile: and I first want to enjoy a working system that fits my open source composing needs. We need a DAW to do composing.

Hence, in the coming weeks we will use Zynthian. I really hope that my earlier feedback is not perceived as criticism. I still believe that Zynthian can be a Gamechanger for the traditional Synthesizer market. 35 Synthesizers in a small box is amazing. It just needs to improved robustness and some Steve Jobs blend: more marketing power and better estetics.

1 Like
2

Totally agree, @Jan!
But please, remember the most important thing you have to do now:

:face_with_monocle:

(i suposse you don’t want the ravens knocking your window you at midnight, you know …)

All the best,

1 Like
3

Hi @Jan !

It would be nice to generate and make avaiable from webconf these “rg” files, and also for other DAWs. FYI, there is a “static API” (the ZynAPI) that allows to query the engines and get the list of banks and presets, so no need for parsing the file system.

Would you like to add such a module to the webconf?

Regards,

4

Sounds good. Where can I find the specification of the ZynAPI in the Zynthian wiki. I will update my scripts accordingly. Can I query every engine, without loading it in Zynthian, as I need only the list of bank and preset for each bank information, without loading the applicable engine?

After adapting the scripts we could add to Zynthian Web conf. Even though I suggest increasing robustness before adding features. Maybe we can organize a webcall. It shows come quite weird behavior when using Zynthian with DAW. In my view robustness is the greatest addition to Zynthian as MVP.

5

Evolution is a wonderful thing so the word stable is probably uppermost in the zynthian hive mind at the moment :slight_smile: So the construction of the Interfaces and the surrounding documentation is something that might usefully be considered in anticipation of the new development branch going forward.

Robustness is a by product of a stable branch. And as with most successful API documentations it really should be derived from the source code itself. So that’s probably where we should look.

We have a considerable number of connected entities from simple MIDI keyboards to DAW environments, and all shades in between.

It’s not so much the want of an API definition as a clear delineation of the model of the objects in the Namespace.

image
image725×925 60.1 KB

The closest we have to this concept are the soundcard properties.
It, perhaps, isn’t too greater leap of faith to imagine

1/ A far wider range of entities than the limited set offered here. i.e a Rosegarden instance…
2/ The ability to define multiple instances.

Presumably this is really something that should be defined in the semantics we use elsewhere and lv2 seems and it’s use of the RDF (RDF - Semantic Web Standards) to map these concepts seem to be a fruitful area of discussion.

http://drobilla.net/docs/lilv/

6

Ok, what I need from you guys is:

  • Location of the API, e.g. , accessble via /engine-api/xyz. or whatever
  • API is xml/json/whatever format spec
  • Few examples
  • Reference to the source code (for more info)

Just a 1 pager, here or in the wiki. Plain and simple

Currently I need to spend hours to reverse engineer everything. That keeps me too long from the objective to add the requested functions.

2 Likes
7

I will give you these tools :wink:

Regards

8

Great ! Meanwhile I will download the latest midi_bank_change branch to test it. Many thanks @jose

1 Like