Re: [LAU] A text-only environment for composing electronic music?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25.01.2014 17:04, Florian Paul Schmidt wrote: [snip] Now I get into the habit of replying to myself, since I missed to mention some points. Caution: Wall of text ahead! :D Mario also wrote: "[...] I am aware of the KISS principle and actually love it very much. So if anyone has suggestions on how to implement such a workflow/tool with existing tools and plumbing code, I am very open to ideas and suggestions. However, I get a feeling that what I want is only convenient if relatively tightly integrated, so that I do not have to tinker with too many individual tools while trying to be productive. [...]"

I fully agree. I'm also not a fan of creating numerous connections myself, be it either in the jack graph nor in modular synths. And especially redoing all these connections again if I forgot to store the connections for the current projects using e.g. the excellent aj-snapshot. Integrated packages like Ardour or Renoise provide lots of convenience in that they allow one to build up a relatively complex project and have all state be stored/restored at once as long as one is willing to stay contained in the boundaries of that particular program. And those programs are graphical by nature and thus almost by definition less hackable than a more KISS/modular approach. On the other end of the spectrum we have session managers like non, lash, ladish, jack_session, etc. They partly solve the session storing and restoring problem but do not help with integration. The integration part is the interesting one. It's the part that allows one to be not only effective, but furthermore efficient. I.e. get results with relatively few actions. For my electronic music projects I do not care too much about recording audio. I'm more interested in generating audio. So what follows is based on my preferences of making electronic music. Maybe they overlap with yours. I have a rough idea on how to realize such a setup. But there are some parts missing. First of all: I'm not all opposed to user interfaces other than script language bindings. Ideally all those interfaces that go beyond directly scriptable stuff are console/text based because a] They are more accessible than graphical user interfaces (or at least a little bit easier to make accessible than GUIs). See my recent post asking for feedback on teqqer and whether it's usable from e.g. braille interfaces. b] They make you think rather hard about supporting the keyboard. Every action that requires a mouse is aside from a few exceptions an action that is hard to hack/script/extend. c] They force users to use the keyboard. While maybe initially a hurdle, this leads to boosted productivity in ideal circumstances. All those interfaces should be hackable and should therefore be implemented in a scripting language that allows easy tinkering if the interface has shortcomings. So let's identify some core components for my imagined environment: 1.] A sequencer component. I like the tracker style approach to sequencing for electronic music. That's why I started to implement teq/teqqer. teq is a c++ sequencing backend with python bindings that allows programatically creating patterns/songs. teqqer is a console UI on top of that which is developed with the explicit goal of being hackable (one goal is to make the user options themself be scripts with full control over what actions perform in the sequencer). teq does not only support jack_midi, but also sending control values over jack audio ports (though this part of the implementation is still WIP) which would allow sample accurate control of control parameters for instruments/hosts that expose their control ports in such a manner. I'm in discussion with falkTX (Felipe) in how to implement this in his 2.0 branch of Carla. teq/teqqer has preliminary support for jack_transport (as of 5 am this morning ;D) 2.] A mixer/instrument abstraction component. This part is unsolved yet but is also the really interesting part. The common usecase for my personal workflow is this: 2a.] There exist N instruments (Samplers, VST/LV2/DSSI-Instruments, etc). 2b.] For each instrument I_n there is an associated mixer strip M_n (a collection of plugins where signal flows linearly from the top to the bottom - a "rack"). 2c.] There exist M mixer strips B_n without an associated instrument ("busses"). 2c.] And finally there's a master section into which all mixer strips feed and which provides again a rack of effects for mastering (dynamics, stereo processing, etc.). The plan for 2] is to build again a scripting language library and associated console UI which streamlines the process of setting these up. In contrast to teq/teqqer in the sequencing component my plan here is to reuse existing components as much as possible. Instrument loading could be performed by Carla. Effect racks could be provided by a different host, maybe mod-host, or jack-rack (though jack-rack is neither hackable nor really accessible) or again by Carla. Carla provides an OSC interface over which all the plugin setup could be performed an it even provides a "rack mode". It is thus scriptable, while at the same time being not really hackable due to its complexity. But without making the effort of reinventing the wheel and implementing yet another plugin hosts. compromises have to be made. And falkTX is a cool guy and open to suggestions. So carla is my plugin host of choice. The envisioned library interface could be used in a way similarly to this (pseudo code): import mixer m = mixer.mixer() m.add_instrument("Aspect") # This only for instruments that provide a GUI and are not hackable/scriptable for those parts: m.instruments[0].show_gui() m.instruments[0].add_plugin("foldover_distortion") m.instruments[0].plugins[0].set_parameter("gain", 0.8) m.master.add_plugin("sc4") m.master.plugins[0].set_parameter("threshold", 0.7) and the library would care about loading the plugins into the plugin host (carla), looking up plugin names and ports by name (substring search etc.) and maintaining jack connections for the signal flow. Alternatively a simple console based UI can be provided on top of this library. If someone's interested in working with me on this, do not hesitate to contact me. 3] A jack patchbay. The scriptable part is there: jack_connect, jack_disconnect and aj-snapshot especially together with working bash_completion are a powerful combo. Sadly the bash completion for jack_connect seesms to be somewhat broken in ubuntu 13.10. the jack_patchbay would only be needed to a] hook up ports from the sequencer to the mixer or b] setting up connections that fall outside of the scope of the mixer abstraction provided by the previous component. Here again a simple console based UI might be provided on top of these tools. 3.] What brings it all together: 3a.] A screen/tmux session where different components are loaded onto different screens. E.g. teqqer on screen 0, a mixer/instrument abstraction on screen 1, a jack patchbay on screen 2, a session handler on screen 3, etc.. There's an unclear part about the interaction of the session handling with the terminal multiplexer. Oh well, this mail is already long enough. I'm open for discussions as this topic is dear to my heart and the reason I started implementing teq/teqqer. Have fun, Flo _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user