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

[Patrick Shirkey]

On Sun, January 26, 2014 10:46 pm, Florian Paul Schmidt wrote:
> -----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.
> [...]"
>

One of the other potential uses for a text only environment is to run your
synth on a dedicated or virtual server using jack with the dummy sound
device. That way you get the added benefit of leaving your synth
environment always on. When you feel like making some tunes just connect
to your icecast stream and start making music. You could even do it all
from the beach on your laptop. Let the server do the heavy lifting for
you.

I have found that a single core machine with 2GB of RAM is enough to be
practically useful.

Of course you pay a monthly fee for this privilege but if you find a good
hosting company that doesn't charge too much it's a lot cheaper than
paying for studio time and may be more viable than using a band room for
practicing too.

Plus it's real easy to share your progress with your band members and
friends.




> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>


--
Patrick Shirkey
Boost Hardware Ltd