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:
> I don't see the original message on this list, so I'll just reply
> to this one. You might have seen my recent post about the ongoing
> development of teqqer (a console based tracker style midi/cv
> sequencer). It is based on a simple library called teq [1] which
> provides a pattern/tracker based abstraction for playing midi/cv
> events over jack ports.
[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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS5PV9AAoJEA5f4Coltk8Z4pMH/3FwjxIDQ2b3/kt/Hw4lDjiV
G7oBK5cCRHFo1bkaAlN9Oltpa+9iDKwIlWh8WNd5dNC7C8dH7Cpws6NtQ2qTPePk
/CoYYKvU/gbh8pnrDUdrXIMGNjZPPg0o63Doc7sp8dGbsgViHwmnWMlHNdsTQZiu
fXGfqx0m6Wxk/IaEM7/dQDJ5EhR2gphQye8f/Hb4JmLPAZcCnQAD8wvjXJkTEEeb
IQ17wWdNm1wrwPuosi2dRZnwLlXlRjj/3P7qK1QWoV4USckI0Wqmxp3/VlC5uHsp
lJEZm0bxOBG50ARNZxe0ZkdtFUebBnufmy63Uxz+1WnfJ6bWhzybdOhrKbQxE1s=
=xmDQ
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Jan 26 16:15:03 2014