5 Nov
2002
5 Nov
'02
11:43 a.m.
Hello.
I'm a blind Linux user since 1997, and I'm also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
Well, since blind people are still very GUIdisabled in Linux, the only things I can use
are those which are either
CLI or curses based,
or expose their functionality through a easily programmable
API.
If only choice number two is available, that isn't that nice, because I'd like to
be productive sometimes, and if you have to write yourself
every little bit of convenience thing, you are not really making music, you're
programming :).
THe biggest problem there is that you actually
dont do much realtime modifications. And realtime
changes to sequences or parameters of things are very important
for experimental type of electronic music.
SO I've looked around, and found some stuff, but
still have nothing really useful.
Here is the list of software which is nicely
done, and GUIless friendly:
Ecasound!!! Kai, cool done! But its not the thing I need
unfortunately.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
Ardour is also somewhat accessible from what I hear, but
again, its a multitrack recorder, not what I need.
SSM: I looked at the code, and it seemed quite
horrible to me. GUI and workhorse code are tightly coupled, I see
no way for me to get to the underlying functionality.
What I'm really missing is:
Some Sequencer which is capable of MIDI out and in
Some Synth software which is controllable through that
sequencer. SSM seems nice, but its a GUI-only thing,
PD is even more GUI...
Some LADSPA plugins seem promising, but again its too much
putting-things-together work.
Can anyone add anything to that list?
Can anyone help with the listed problems?
Is some software author (i.e., the SSM author) interested
to work with me on getting GUIless controllability?
I'm not a good C programmer, but I'm at least
familiar with what we'd need to work efficiently...
Or am I missing anything completely? Some trick
to circumvent the need for some GUIs? Can anyone
give an example on how to create a short trtack
with some samples and a synth line without X?
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang(a)db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
5 Nov
5 Nov
12:26 p.m.
On Tue, Nov 05, 2002 at 04:39:41PM +0100, Mario Lang wrote:
I'm a blind Linux user since 1997, and I'm
also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
GDAM does have a decent sequencer, with interfaces for step sequencing
and live-play input, pattern banks, etc. It would be quite simple to
cram into gdam123, or better yet its own little command-line app.
However, it works with samples not synths. To work with synths
we'd need to add midi out. Adding midi out wouldn't be terribly
hard, but there might be another app which already meets your
requirements.
There is also some long-term work to add a synth engine as well as full
automation of all gdam and ladspa plugins to our sequencer (ala buzz)
but i wouldn't hold your breath waiting for it.
-geoff
7:31 p.m.
Lance Blisters <geoff(a)lek.ugcs.caltech.edu> writes:
On Tue, Nov 05, 2002 at 04:39:41PM +0100, Mario Lang
wrote:
Yes, I've seen the demo-seuqencer.c file. My main problem there was
that I didn't find the whole API documented nicely anywhere, and am
not able to try the seuqencer out as it stands, as I'm not able to use
X. This makes figuring out how it's supposed to work a bit
cumbersome. So there's a bit of a chicken-egg problem again.
I'm a blind Linux user since 1997, and
I'm also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
GDAM does have a decent sequencer, with interfaces for step sequencing
and live-play input, pattern banks, etc. It would be quite simple to
cram into gdam123, or better yet its own little command-line app. However, it works with samples not synths. To work
with synths
we'd need to add midi out.
Doesn't GDAM work with LADSPA? Wouldn't that allow software based
synths in the sequencer?
--
CYa,
Mario
12:49 p.m.
What about csound? This is a command line and text based program for
handling synth stuff. Check out http://www.csounds.com
Matt
On Tue, 5 Nov 2002, Mario Lang wrote:
Hello.
I'm a blind Linux user since 1997, and I'm also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
Well, since blind people are still very GUIdisabled in Linux, the only things I can use
are those which are either
CLI or curses based,
or expose their functionality through a easily programmable
API.
If only choice number two is available, that isn't that nice, because I'd like
to
be productive sometimes, and if you have to write yourself
every little bit of convenience thing, you are not really making music, you're
programming :).
THe biggest problem there is that you actually
dont do much realtime modifications. And realtime
changes to sequences or parameters of things are very important
for experimental type of electronic music.
SO I've looked around, and found some stuff, but
still have nothing really useful.
Here is the list of software which is nicely
done, and GUIless friendly:
Ecasound!!! Kai, cool done! But its not the thing I need
unfortunately.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
Ardour is also somewhat accessible from what I hear, but
again, its a multitrack recorder, not what I need.
SSM: I looked at the code, and it seemed quite
horrible to me. GUI and workhorse code are tightly coupled, I see
no way for me to get to the underlying functionality.
What I'm really missing is:
Some Sequencer which is capable of MIDI out and in
Some Synth software which is controllable through that
sequencer. SSM seems nice, but its a GUI-only thing,
PD is even more GUI...
Some LADSPA plugins seem promising, but again its too much
putting-things-together work.
Can anyone add anything to that list?
Can anyone help with the listed problems?
Is some software author (i.e., the SSM author) interested
to work with me on getting GUIless controllability?
I'm not a good C programmer, but I'm at least
familiar with what we'd need to work efficiently...
Or am I missing anything completely? Some trick
to circumvent the need for some GUIs? Can anyone
give an example on how to create a short trtack
with some samples and a synth line without X?
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang(a)db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
1:52 p.m.
On Tue, Nov 05, 2002 at 10:46:12AM -0600, Matt Gerassimoff wrote:
What about csound? This is a command line and text based program for
handling synth stuff. Check out http://www.csounds.com
or SAOL, which you can use on linux thanks to sfront.
sort of like "new improved" csound.
http://www.cs.berkeley.edu/~lazzaro/sa/
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
7:33 p.m.
Paul Winkler <pw_lists(a)slinkp.com> writes:
On Tue, Nov 05, 2002 at 10:46:12AM -0600, Matt
Gerassimoff wrote:
Yes, both are nice, but both have the same problem for me. It's not easy to
get actual instruments going... At least not for me. It was always
quite complicated to produce anything on my own, and there are just
not man public instrument sources which are actually usable imo.
--
CYa,
Mariok
What about csound? This is a command line and text based program for
handling synth stuff. Check out http://www.csounds.com
or SAOL, which you can use on linux thanks to sfront.
sort of like "new improved" csound.
http://www.cs.berkeley.edu/~lazzaro/sa/
7:52 p.m.
On Wed, Nov 06, 2002 at 12:29:13AM +0100, Mario Lang wrote:
Yes, both are nice, but both have the same problem for me. It's not easy to
get actual instruments going... At least not for me. It was always
quite complicated to produce anything on my own, and there are just
not man public instrument sources which are actually usable imo.
it's true, there's some programming overhead.
Butt there are quite a lot of nice csound instruments on the net.
Not so many for saol, unfortunately.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
What about csound? This is a command line and text
based program for
handling synth stuff. Check out http://www.csounds.com
or SAOL, which you can use on linux thanks to sfront.
sort of like "new improved" csound.
http://www.cs.berkeley.edu/~lazzaro/sa/ 
1:10 p.m.
SSM: I looked at the code, and it seemed quite
horrible to me. GUI and workhorse code are tightly coupled, I see
no way for me to get to the underlying functionality.
Things are going in the right direction, the audio code is now seperate from
the rest of the app at least. You can currently (from CVS) run ssm without a
GUI at all, it just loads a patch and plays it until you hit ctrl-c. I
intended this for using midi only control (but you still have to use the GUI
to build the patch in the first place of course).
Is some software author (i.e., the SSM author)
interested
to work with me on getting GUIless controllability?
I am interested in doing a GUIless interface for ssm, and I have been thinking
about it for some time.
I think making a text based patch builder for ssm would be fairly easy, i.e
"connect oscillatorA.output to envelopeB.audio_in" but changing the modules
parameters in realtime might be a bit more difficult.
The real problem, as you noticed is that the plugins have all the fltk code
built in :( (a design decision for other very GUI-centric reasons). However, a
side effect of having to make the code threadsafe is that all control data
from the gui widgets now have to be passed though a "channelhandler" class
which deals with all the mutexes etc. These channels even have plain text
names that make sense in the context of the plugin.
So I think it may be possible to write another app, which is compatible with
ssm's plugins and redirects (by overloading the channelhander) the control
data from a keyboard based interface. In theory :)
Another possibility that might make more sense (something else I've been
thinking about) is a LADSPA only modular synth - as LADSPA plugins are much
less bound to a GUI than ssm's the interface could be much more textual.
I'll think more about the possibilities of modifing ssm, but the bad news is
that I have a todo list pages long at the moment :( :( :(
Cheers,
dave
1:51 p.m.
On Tue, Nov 05, 2002 at 06:06:47 +0100, Dave Griffiths wrote:
Another possibility that might make more sense
(something else I've been
thinking about) is a LADSPA only modular synth - as LADSPA plugins are much
less bound to a GUI than ssm's the interface could be much more textual.
Several people have discussed this idea, its one that is particularly
close to my heart, as I love both :)
Combined with Juan Linietsky's dynamic compilation idea, this would be
very powerful, and something the closed source people can't really do.
I think Matthias Nagorni said it was a long term goal for ALSA Modular
Synth, but the gui stuff just isn't there yet.
- Steve
6:37 p.m.
On Tue, 5 Nov 2002 17:47:36 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Tue, Nov 05, 2002 at 06:06:47 +0100, Dave Griffiths
wrote:
Amen to that! I've been thinking on these lines as well. I like ssm for
its speed and flexibility, and ecasound for the text interface and
design - having a core 'engine' for which multiple interfaces can be
created.
A text interface with tab completion (especially when there's a lot of
plugins in the network) would be a nice feature. Another idea which I've
seen discussed is the creation of 'meta' plugins - subnetworks 'wrapped'
into a single plugin. Combined with cut,copy,paste, you could create a
nice patch, and then decide 'I want six of them, each slightly detuned'
or something, and simply replicate the meta plugin five times.
Provided the interface to the engine is well designed, it should be
possible to create any kind of UI - even perhaps one that could be
controlled using an external MIDI device.
Realtime control of parameters such as frequency cutoff, reverb room
size and such could be via MIDI controller values. I think these allow
quite a bit of resolution - 14bit? Must check.
I'm going to go and flesh some of this out a bit more, as it's been on
my mind for quite a while. I was unsure of writing any actual code,
because there seem to be loads of modular synths about already...
Ramble over...
Another possibility that might make more sense
(something else I've
been thinking about) is a LADSPA only modular synth - as LADSPA
plugins are much less bound to a GUI than ssm's the interface could
be much more textual.
Several people have discussed this idea, its one that is particularly
close to my heart, as I love both :)
Combined with Juan Linietsky's dynamic compilation idea, this would be
very powerful, and something the closed source people can't really do.
... off to search archives for 'dynamic compilation' :)
-
Myk
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
7:46 p.m.
On Tue, Nov 05, 2002 at 10:42:14PM +0000, Mike Rawes wrote:
A text interface with tab completion (especially when
there's a lot of
plugins in the network) would be a nice feature.
just to put in my 2 cents... I think a relatively high-level
language would be best for building this text interface.
You could work on it a lot quicker and the performance issues
would be negligible. I'd use python, personally.
I have long wanted to do an interactive text interface
to omde (http://omde.sf.net)
--PW
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
6 Nov
6 Nov
7:22 a.m.
On Tue, Nov 05, 2002 at 03:43:17 -0800, Paul Winkler wrote:
On Tue, Nov 05, 2002 at 10:42:14PM +0000, Mike Rawes
wrote:
If you want a high level graph language, then dot would do a reasonable
job. You have added advantage that you can dernder it to make pretty
pictures if you want ;)
- Steve
A text interface with tab completion (especially
when there's a lot of
plugins in the network) would be a nice feature.
just to put in my 2 cents... I think a relatively high-level
language would be best for building this text interface.
You could work on it a lot quicker and the performance issues
would be negligible. I'd use python, personally.
I have long wanted to do an interactive text interface
to omde (http://omde.sf.net)
5 Nov
5 Nov
7:48 p.m.
oops, omde is at
http://sf.net/projects/pythonsound
--PW
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"
8:22 p.m.
On Tue, 5 Nov 2002, Mike Rawes wrote:
plugins in the network) would be a nice feature.
Another idea which I've
seen discussed is the creation of 'meta' plugins - subnetworks 'wrapped'
into a single plugin. Combined with cut,copy,paste, you could create a
nice patch, and then decide 'I want six of them, each slightly detuned'
or something, and simply replicate the meta plugin five times.
Btw; ecasound provides these. Ecasound's meta plugins, or in ecasound's
terms, effect presets, can combine native and LADSPA plugins, and locate
them in parallel and serial chains, and it's also possible to parametrize
the meta plugins (ie. one meta-plugin parameter can control multiple
"real-plugin" parameters). See more info at:
http://www.wakkanet.fi/~kaiv/ecasound/Documentation/users_guide/html_uguide…
Or alternatively: eca.cx/ecasound -> documentation -> user's guide
Realtime control of parameters such as frequency
cutoff, reverb room
size and such could be via MIDI controller values. I think these allow
quite a bit of resolution - 14bit? Must check.
This is also possible with ecasound.
ecasound -f:32,1,44100 -i jack -o jack \
-ef3:800,1.5,0.9 -km:1,400,4200,74,0 -km:2,0.1,1.5,71,0
This creates a JACK client that has one input and one output
port. During process() ecasound will take the data sent to its
input port, process it with a lowpass filters, and write it to
the output port.
The lowpass filter is controlled in real-time with MIDI-CC 74 (cutoff) and
71 (resonance). The whole -km syntax is:
-km:parameter,range_low,range_high,controller_number,midi-channel
Support for 14bit MIDI controllers is not yet available, but has been
on my todo-list for a while (see edi-4 at eca.cx/ecasound -> EDIs).
Although ecasound is not an optimal platform for creating audio generating
apps, it can manage quite a few simple cases. For instance:
ecasound -f:32,1,44100 -i null -o jack \
-el:analogueOsc,1,440,1,1 -km:2,40,16000,74,0
... creates a JACK client that outputs sine wave (using the analogueOsc
LASDPA plugin) to its output port. The osc frequency is controlled using
MIDI-CC 74.
If you don't have MIDI-equipment at your use, you can test the above by
replacing -km with -kos:2,40,16000,0.5,0 ... Also, if you are not running
JACK, replace 'jack' with either '/dev/dsp' or 'alsa,default'.
For more complicated MIDI-control, you could write an ECI app in
perl/php/python/lisp (or even in C/C++ :)) that reads from /dev/midi00,
interprets the MIDI messages in some way, and then sets the LADSPA plugin
parameters (in real-time) by issuing ECI commands.
The ECI API might look a bit too simple, but it has proven to be quite
versatile. For instance, last week I implemented a VU-meter
(ecasignalview) using nothing but ECI. And even better, soon after, Mario
Lang implemented a similar real-time VU-meter to ecasound's emacs-mode
using the (e)lisp ECI API...! Do that in vi! ;)
But, but, implementing a full MIDI-controllable synth this way is
probably not a good idea. :) Ecasound has a few critical limitations
that can cause problems:
- impossible to freely route data between plugin audio ports
- changing object connections cannot be done in real-time (ie.
you'll hear a clear break)
- no direct access to actual audio data, just the object parameters
--
http://www.eca.cx
Audio software for Linux!
6 Nov
6 Nov
4:27 p.m.
On Wed, 6 Nov 2002 02:18:30 +0200 (EET)
Kai Vehmanen <kai.vehmanen(a)wakkanet.fi> wrote:
[...loads of useful ecasound info...]
The ECI API might look a bit too simple, but it has proven to be quite
versatile.
I wasn't criticising it's simplicty - it's a compliment :) A similar
interface/abstraction for more modular synthy purposes would be cool
though. 'mesh' and 'mesh-setup' if you like.
-
Myk
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
5 Nov
5 Nov
7:34 p.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
[...]
I think Matthias Nagorni said it was a long term goal
for ALSA Modular
Synth, but the gui stuff just isn't there yet.
A project where the GUI isn't there yet? Oh, I love it already.
What is it? :)
--
CYa,
Mario
6 Nov
6 Nov
7:23 a.m.
On Wed, Nov 06, 2002 at 12:31:07 +0100, Mario Lang wrote:
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
[...]
AMS has a gui, I was refering to the lack of LADSPA gui.
- Steve
I think Matthias Nagorni said it was a long term
goal for ALSA Modular
Synth, but the gui stuff just isn't there yet.
A project where the GUI isn't there yet? Oh, I love it already.
What is it? :)
9:47 a.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
On Wed, Nov 06, 2002 at 12:31:07 +0100, Mario Lang
wrote:
Oh, IC. Just checked it
out, and had to feel that terrible
feeling of "I want this, but cant..." again.
The *.ams files looks textual to me, anyone experienced enough
with AMS able to comment on if it is remotely thinkable
to turn it into a alternatively-controllable-app? Like
a simple socket interface to change controls?
--
CYa,
Mario
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
[...]
AMS has a gui, I was refering to the lack of LADSPA gui. I think Matthias Nagorni said it was a long term
goal for ALSA Modular
Synth, but the gui stuff just isn't there yet.
A project where the GUI isn't there yet? Oh, I love it already.
What is it? :) 
10:10 a.m.
Hi,
I've nearly finished an updated DMIDI client which allows AMS, and any
ALSA 0.9 app, to be controlled remotely on a LAN. The 0.2 version just
dumps received data to /dev/midi.
I've one bug which need to be fixed and some slight refactoring of the
output side before it can be released but it works well.
If anyone is interested in playing with this version drop me a note.
Perhaps you can help?
Cheers
Phil
On Wed, 2002-11-06 at 13:43, Mario Lang wrote:
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
On Wed, Nov 06, 2002 at 12:31:07 +0100, Mario
Lang wrote:
Oh, IC. Just checked it
out, and had to feel that terrible
feeling of "I want this, but cant..." again.
The *.ams files looks textual to me, anyone experienced enough
with AMS able to comment on if it is remotely thinkable
to turn it into a alternatively-controllable-app? Like
a simple socket interface to change controls?
--
CYa,
Mario Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
writes:
[...]
AMS has a gui, I was refering to the lack of LADSPA gui. I think Matthias Nagorni said it was a long term
goal for ALSA Modular
Synth, but the gui stuff just isn't there yet.
A project where the GUI isn't there yet? Oh, I love it already.
What is it? :)
10:20 a.m.
Mario,
Could you give some descriptions of a text based interface you would like to
use for realtime control of a modular synth? The building of patches seems
fairly easy (via a CLI), but I'm thinking you'd want a more direct control for
actually playing the thing - mapping the parameters to different keys maybe?
Cheers,
Dave
10:42 a.m.
On Wed, Nov 06, 2002 at 03:16:37PM +0100, Dave Griffiths wrote:
Mario,
Could you give some descriptions of a text based interface you would like to
use for realtime control of a modular synth? The building of patches seems
fairly easy (via a CLI), but I'm thinking you'd want a more direct control for
actually playing the thing - mapping the parameters to different keys maybe?
A MIDI slider box? That my prefered way of controling modualr synths, and
it doesn't require a GUI.
- Steve
11:29 a.m.
"Dave Griffiths" <dave(a)pawfal.org> writes:
Mario,
Could you give some descriptions of a text based interface you would like to
use for realtime control of a modular synth? The building of patches seems
fairly easy (via a CLI), but I'm thinking you'd want a more direct control for
actually playing the thing - mapping the parameters to different keys maybe?
Let me explain. The building of patches is what currently
doesnt work at all, so if a cli is easy to write for that, that would help ALOT!
I think you shouldn't concern yourself with a realtime interface
for the blind. We'll handle this ourselves. What is important
is that every vital and important bit of information is exposed
via a clean cli interface. I can write my own realtime controllers
for such a cli pipe if I need to for instance, take ecasound.el,
it is nothing else than a emacs interface to the ecasound cli, and
it is already at a point where I created a special widget which can
"slide" by pressing + or - on it.
Whats important is that you expose information like
available plugins and their parameters also through
your cli, much like *-register and map-*-list in ECI.
Another thought is, controllers could easily be controlled
using MIDI CC, and infact I have a midi-keyboard.
We could also try and write a blind-friendly virtual
midi keyboard at some point...
So please dont concern yourself with things like "how should
a ui for the blind look like...".
If you offer a truly complete CLI to your program,
and document it + some examples, we'll be able
to work on from there...
Otherwise, if you really wanna try to write a ncurses-like
realtime interface, just do it, if you can cope with it,
I can too :). The only thing which is important
is that there is a cli too...
P.S.: The CLI is not only good for us blind people,
there are alot of benefits for such an interface, think
scripting.
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang(a)db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
12:23 p.m.
"Dave Griffiths" <dave(a)pawfal.org>
writes:
> Mario,
>
> Could you give some descriptions of a text based interface you would like
to
> use for realtime control of a modular synth? The
building of patches seems
> fairly easy (via a CLI), but I'm thinking you'd want a more direct
control for
> actually playing the thing - mapping the
parameters to different keys
maybe?
Let me explain. The building of patches is what currently
doesnt work at all, so if a cli is easy to write for that, that
would help ALOT!
Ok, I'll have a look at doing this.
P.S.: The CLI is not only good for us blind people,
there are alot of benefits for such an interface, think
scripting.
Also load/save files can simply become a list of commands for building the
patch. I believe this is how PD works, so maybe that has some potential too.
dave
2:56 p.m.
On Wed, 6 Nov 2002, Dave Griffiths wrote:
I think ecasound has provided a perfectly good example to follow. The
engine should be runnable as a daemon and there needs to be a real-time
control syntax. That way, any number of scripts or guis can be built for
special or general purposes.
Bill
"Dave
Griffiths" <dave(a)pawfal.org> writes:
> Mario,
>
> Could you give some descriptions of a text based interface you would like
to
> use for realtime control of a modular synth?
The building of patches seems
> fairly easy (via a CLI), but I'm thinking you'd want a more direct
control for
> actually playing the thing - mapping the
parameters to different keys
maybe?
Let me explain. The building of patches is what currently
doesnt work at all, so if a cli is easy to write for that, that
would help ALOT!
Ok, I'll have a look at doing this.
P.S.: The CLI is not only good for us blind
people,
there are alot of benefits for such an interface, think
scripting.
Also load/save files can simply become a list of commands for building the
patch. I believe this is how PD works, so maybe that has some potential too.
dave
2:52 p.m.
On Wed, 6 Nov 2002, Mario Lang wrote:
The *.ams files looks textual to me, anyone experienced enough
with AMS able to comment on if it is remotely thinkable
to turn it into a alternatively-controllable-app? Like
a simple socket interface to change controls?
I've used AMS quite a lot - I like the sounds and controls. However, my
review of the code revealed that the gui and synthesis engine were fairly
tightly entertwined. The *.ams files refer specifically to the gui
elements that are present in the patch. It does this because when you save
a patch, you are not only saving the patches circuit, but also the look
and feel of the patch, i.e. the positions on the screen at which the
various elements have been placed. This is nice since one can load a patch
the next day/week/whatever and have a visual reminder of the patch and its
connections.
I would love to see a separation of the gui part from the synth part, but
I'm not sure how to specify the connections between the two. I suppose one
could name (or number as AMS does automatically) the elements in the
circuit, then refer to those elements in the gui description that
specifies the placement of the element on the screen. If you had that, you
could have multiple gui layouts for a given circuit, plus the ability to
specify patches strictly textually.
Bill
3:15 p.m.
Bill Allen <ballen(a)mail.serve.com> writes:
On Wed, 6 Nov 2002, Mario Lang wrote:
>
> The *.ams files looks textual to me, anyone experienced enough
> with AMS able to comment on if it is remotely thinkable
> to turn it into a alternatively-controllable-app? Like
> a simple socket interface to change controls?
[...]
I would love to see a separation of the gui part from
the synth part, but
I'm not sure how to specify the connections between the two. I suppose one
could name (or number as AMS does automatically) the elements in the
circuit, then refer to those elements in the gui description that
specifies the placement of the element on the screen.
I think that sounds like a very good way to do it.
If you had that, you could have multiple gui layouts
for a given
circuit, plus the ability to specify patches strictly textually.
And you could easily add a simple cli which does nothing else than
list the available controls of the loaded patch, and offer set/get
operations to query and set those controls.
This mini-controller app could also do MIDI assignment, if you
add commands to assign MIDI CCs to certain controllers, you can
use it to load a midi-to-patch mapping file. But that maybe
already works differently, I'm not too familiar with AMS.
--
CYa,
Mario
3:24 p.m.
On Wed, Nov 06, 2002 at 01:49:22 -0500, Bill Allen wrote:
On Wed, 6 Nov 2002, Mario Lang wrote:
But that is not true of the LADSPA based modules (obviously) and they are
intended to be the bulk of the synthesis longterm.
- Steve
The *.ams files looks textual to me, anyone experienced enough
with AMS able to comment on if it is remotely thinkable
to turn it into a alternatively-controllable-app? Like
a simple socket interface to change controls?
I've used AMS quite a lot - I like the sounds and controls. However, my
review of the code revealed that the gui and synthesis engine were fairly
tightly entertwined. The *.ams files refer specifically to the gui
elements that are present in the patch. It does this because when you save
a patch, you are not only saving the patches circuit, but also the look
and feel of the patch, i.e. the positions on the screen at which the
various elements have been placed. This is nice since one can load a patch
the next day/week/whatever and have a visual reminder of the patch and its
connections. 
10:05 a.m.
This is something I have done a fair bit of work on myself. I have an
almost complete working engine, which allows polyphonic, multitimbral
operation, and has a mixer with a channel per part, inserts and as many
output buses as you want. No GUI code as yet (except for some old code in
a pervious incarnation). The engine and GUI stuff have been written right
from the start to be completely separate, so a command line interface
should be easy.
I started off doing my own home-spun plugin api, but when it came down to
it, the only difference was that there were contorl, output and input
ports, rather than just ports. So it made more sense to just use LADSPA,
and provide a separate library of plugins that the synth used, that could
be used elsewhere too.
Ian
Another possibility that might make more sense
(something else I've been
thinking about) is a LADSPA only modular synth - as LADSPA plugins are
much less bound to a GUI than ssm's the interface could be much more
textual.
5 Nov
5 Nov
1:18 p.m.
You could also try keykit which has both a GUI and non-GUI interface.
It's at http://www.nosuch.com/keykit
Matt
On Tue, 5 Nov 2002, Mario Lang wrote:
Hello.
I'm a blind Linux user since 1997, and I'm also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
Well, since blind people are still very GUIdisabled in Linux, the only things I can use
are those which are either
CLI or curses based,
or expose their functionality through a easily programmable
API.
If only choice number two is available, that isn't that nice, because I'd like
to
be productive sometimes, and if you have to write yourself
every little bit of convenience thing, you are not really making music, you're
programming :).
THe biggest problem there is that you actually
dont do much realtime modifications. And realtime
changes to sequences or parameters of things are very important
for experimental type of electronic music.
SO I've looked around, and found some stuff, but
still have nothing really useful.
Here is the list of software which is nicely
done, and GUIless friendly:
Ecasound!!! Kai, cool done! But its not the thing I need
unfortunately.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
Ardour is also somewhat accessible from what I hear, but
again, its a multitrack recorder, not what I need.
SSM: I looked at the code, and it seemed quite
horrible to me. GUI and workhorse code are tightly coupled, I see
no way for me to get to the underlying functionality.
What I'm really missing is:
Some Sequencer which is capable of MIDI out and in
Some Synth software which is controllable through that
sequencer. SSM seems nice, but its a GUI-only thing,
PD is even more GUI...
Some LADSPA plugins seem promising, but again its too much
putting-things-together work.
Can anyone add anything to that list?
Can anyone help with the listed problems?
Is some software author (i.e., the SSM author) interested
to work with me on getting GUIless controllability?
I'm not a good C programmer, but I'm at least
familiar with what we'd need to work efficiently...
Or am I missing anything completely? Some trick
to circumvent the need for some GUIs? Can anyone
give an example on how to create a short trtack
with some samples and a synth line without X?
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang(a)db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
7:19 p.m.
I'm not sure that it does what you want, but glame is designed with the
engine and gui completely separated. The control language for glame
networks is guile. It has much of the core for a full sequencing system
(tone generators, ladspa plugin support), but no midi support. Domage.
I have always been interested in guiless synthesizers for reasons that
probably have a lot to do with why I'm a devoted ecasound user for my
multitracking needs.
Bill
6 Nov
6 Nov
3:49 a.m.
iiwusynth (http://www.iiwu.org/iiwusynth/) is a command line driven soft
synth based on SoundFont instrument patch files. My program Swami
(http://swami.sourceforge.net) is a patch file editor (currently just
SoundFont files) that has an architecture that is completely separated
from the GUI. It does not currently have a command line interface but
I'm planning on adding a Python binding to it real soon now. I have put
a little thought into a CLI but I don't know when I would actually get
around to writing one. Good luck in finding wonderful sounding solutions
:) Cheers.
Josh Green
7989
days inactive
7990
days old
linux-audio-dev@lists.linuxaudio.org
31 comments
13 participants
participants (13)
-
Bill Allen -
Dave Griffiths -
ian -
Josh Green -
Kai Vehmanen -
Lance Blisters -
Mario Lang -
Matt Gerassimoff -
Mike Rawes -
Paul Davis -
Paul Winkler -
Phil Kerr -
Steve Harris