13 Jan
2004
13 Jan
'04
11:13 a.m.
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
The editor would handle GUIs such as in
AlsaModularSynth,
Arts,
Galan,
Gdam,
Glame,
NMEdit,
PD,
Quasimodo,
SpiralSynthModular.
Also we should have an API and a script in the system.
I can set up a project folder to our ftp site, ftp.funet.fi,
for resources (manuals and screenshots of existing systems, research
papers). Coding should happen in some CVS site.
Any comments?
Regards,
Juhana
13 Jan
13 Jan
11:27 a.m.
On Tue, Jan 13, 2004 at 06:09:55PM +0200, Juhana Sadeharju wrote:
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
I agree, but please contact these people: http://nmedit.sourceforge.net/
they have similar aims.
- Steve
11:46 a.m.
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
On Tue, Jan 13, 2004 at 06:09:55PM +0200, Juhana
Sadeharju wrote:
That looks a bit specific to the Clavia synths, or isn't it?
A more abstract "patch synth" approach might be based on Graphviz, I
think:
http://www.research.att.com/sw/tools/graphviz/
ciao
--
Frank Barknecht _ ______footils.org__
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
I agree, but please contact these people: http://nmedit.sourceforge.net/
they have similar aims.
12:35 p.m.
On Tue, Jan 13, 2004 at 05:43:38PM +0100, Frank Barknecht wrote:
Hallo,
Steve Harris hat gesagt: // Steve Harris wrote:
Only the backend - there was a plan to develop a generic modular synth
frontend that could be used by all modular synth clients, hardware or
software.
- Steve
On Tue, Jan 13, 2004 at 06:09:55PM +0200, Juhana
Sadeharju wrote:
That looks a bit specific to the Clavia synths, or isn't it? Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
I agree, but please contact these people: http://nmedit.sourceforge.net/
they have similar aims. 
11:48 a.m.
FWIW spiralsynth modular's main app is _just_ a GUI (with a plugin loader), it
knows nothing about sound or anything else. The canvas and module widgets are
normal fltk widgets. We've used it for video processing too.
I don't know if I'd recommend it for anything else though...
I've been considering writing a modular gui in tk - PD style (but hopefully a
bit prettier ;P ) I've come to really like using scripting languages (python)
to create GUIs.
On Tue, 13 Jan 2004 18:09:55 +0200, Juhana Sadeharju wrote
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
The editor would handle GUIs such as in
AlsaModularSynth,
Arts,
Galan,
Gdam,
Glame,
NMEdit,
PD,
Quasimodo,
SpiralSynthModular.
Also we should have an API and a script in the system.
I can set up a project folder to our ftp site, ftp.funet.fi,
for resources (manuals and screenshots of existing systems, research
papers). Coding should happen in some CVS site.
Any comments?
Regards,
Juhana
................................. www.pawfal.org/nebogeo
12:13 p.m.
Hallo,
Dave Griffiths hat gesagt: // Dave Griffiths wrote:
I've been considering writing a modular gui in tk
- PD style (but hopefully a
bit prettier ;P )
Pd will probably not stay with tk, and some of its ugliness is rooted
in cross-platform thoughts (like using the Courier font everywhere).
I've come to really like using scripting languages
(python) to
create GUIs.
The jMax folks have been doing some cool stuff with Python recently in
the effort to get rid of the dependency on the proprietary Java. I
think this is a really neat approach.
Regarding a common modular patch editor: although softsynths are
relatives, there are various important differences between them. For
example, the Max family is very dependent on character input: You
create objects by creating a generic object and then giving it a name.
Afterwards the objects stay just that: a word, and it can be treated
like that (search/replace for example).
This is very much different from traditional modular synths that
follow a hardware emulation approach, like AlsaModularSynth or
Reaktor.
And then there are the modular synth languages, that have a GUI as
optional interface, like Csound. Basically they don't need a patch
editor besides Vim/Emacs.
ciao
--
Frank Barknecht _ ______footils.org__
12:51 p.m.
On Tue, 13 Jan 2004 18:09:56 +0100, Frank Barknecht wrote
Hallo,
Dave Griffiths hat gesagt: // Dave Griffiths wrote:
I actually quite like the PD interface, especially after a bit of work, like
your pattern seqencer.
I've been considering writing a modular gui
in tk - PD style (but hopefully a
bit prettier ;P )
Pd will probably not stay with tk, and some of its ugliness is rooted
in cross-platform thoughts (like using the Courier font everywhere). Regarding a common modular patch editor: although
softsynths are
relatives, there are various important differences between them. For
example, the Max family is very dependent on character input: You
create objects by creating a generic object and then giving it a
name. Afterwards the objects stay just that: a word, and it can be treated
like that (search/replace for example).
This is very much different from traditional modular synths that
follow a hardware emulation approach, like AlsaModularSynth or
Reaktor.
With traditional modulars there is also the thorny issue of whether you put
the module's controls in the gui box, or in their own window.
One thing I'd really really want is a patch layout tool for complex graphs
like maya's (whcih uses this: http://www.tomsawyer.com/gallery/gallery.html)
There are a few GPL equivelents, but nothing that can do this AFAIK.
cheers,
dave
................................. www.pawfal.org/nebogeo
3:56 p.m.
Hallo,
Dave Griffiths hat gesagt: // Dave Griffiths wrote:
On Tue, 13 Jan 2004 18:09:56 +0100, Frank Barknecht
wrote
;)
But this will (hopefully) not break with a future toolkit switch. This
pattern sequencer and the other RRADical patches I work on use a Pd
feature, that a lot of, probably most, other graphical softsynths miss:
the ability to create abstraction on higher levels. For example in
Reaktor: once you've built a GUI, you're basically done and set. You
cannot reuse this GUI *inside* another GUI and use that combined GUI
inside another one.
Or compared to programming languages: It's like as if you're allowed
to write functions, but those must not call other functions. Like a
a precompiler macro: This is useful in many situations, but not
powerful enough for more complex ones.
In Pd and some other synths - like Torben's Galan - one patch can
swallow another patch, adapt it in various ways and create a new level
of abstraction. On this level then the same can start again. This is
the most powerful feature in Pd, I think, but also difficult to
understand fully in all its implications.
Anyway: A modular synth, which does not have this feature is missing
something very important IMO. In the end, designing a modular synth is
designing a programming language, and thus all the theory and
knowledge that was developed in language design has to be considered
as well.
Supercollider (and of course Lisp based softsynths) knows this very
well, and even includes things like inheritance (which I truly miss in
Pd.)
(I almost don't know SSM, so I cannot say anything about it in all
this regards.)
Pd will probably not stay with tk, and some of
its ugliness is rooted
in cross-platform thoughts (like using the Courier font everywhere).
I actually quite like the PD interface, especially after a bit of work, like
your pattern seqencer. One thing I'd really really want is a patch layout
tool for complex graphs
like maya's (whcih uses this: http://www.tomsawyer.com/gallery/gallery.html)
There are a few GPL equivelents, but nothing that can do this AFAIK.
This is cool. It looks a bit like a very cool game I once ported
to Linux: http://www.asahi-net.or.jp/~cs8k-cyu/windows/noiz2sa_e.html
(it only required some Makefile fiddling.)
ciao
--
Frank Barknecht _ ______footils.org__
11:52 a.m.
On Tue, Jan 13, 2004 at 06:09:55PM +0200, Juhana Sadeharju wrote:
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
[ snip ]
Any comments?
Pardon my ignorance, but do you mean some kind of synth editor
(like for MIDI synths) but for use with software applications/
libraries instead of MIDI? Or do you mean a GUI library to be
used by other applications? Or maybe some kind of GUI + scripting
language, like tcl/tk?
Curiously awaiting an anwer...
Joost.
1:22 p.m.
Pardon my ignorance, but do you mean some kind of
synth editor
(like for MIDI synths) but for use with software
applications/
libraries instead of MIDI? Or do you mean a GUI
library to be
used by other applications? Or maybe some kind of
GUI + scripting
language, like tcl/tk?
I think they mean a GUI for modular synths like
alsamodular synth where you place down modules and
connect them with cords to make sounds.. like the
modular moogs of yore. Probably more specific/less
generic than tcl/tk; making the assumption that the
program using it works with a module/connections sort
of format.
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
12:25 p.m.
Hi,
I have been thinking about something similar to be used in the nmedit
project. A Modular Synthesizer GUI Framework. It would contain
implementations of useful widgets and handle user interaction, like
module placement, cable connections and module parameter settings. The
framework would then be individually customized for each particular
synthesizer and connected to the synthesizers backends. Unfortunately, I
will not have the time to implement it, but I could contribute with ideas.
Marcus
Juhana Sadeharju wrote:
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
The editor would handle GUIs such as in
AlsaModularSynth,
Arts,
Galan,
Gdam,
Glame,
NMEdit,
PD,
Quasimodo,
SpiralSynthModular.
Also we should have an API and a script in the system.
I can set up a project folder to our ftp site, ftp.funet.fi,
for resources (manuals and screenshots of existing systems, research
papers). Coding should happen in some CVS site.
Any comments?
Regards,
Juhana
1:59 p.m.
I think another great application for such a thing would be a JACK patch
bay. It would be so much easier to use something like this to connect
apps (and internal ardour connections) than it is at the moment. I
always wanted to write such a thing myself but never really had the
time. In many ways a JACK patch bay would be one of the most demanding
applications for this because it has to handle both many-to-one and
one-to-many connections and JACK graphs can be very complicated, so I
would suggest bearing it in mind while designing it, on the grounds that
if it can handle that it will be able to handle many other things as
well. I also think that having the option of embedding synth GUIs into
the graph is very important.
I think the main decision to be made is how much of the layout should be
automated and how much left to the user. On one extreme the user has to
place all the modules and the wires are just straight lines between
them, and on the other the whole thing is laid out by some kind of
optimisation algorithm, with the wires cunningly routing themselves
around obstacles. I think the best option has to be somewhere in between.
Juhana Sadeharju wrote:
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
The editor would handle GUIs such as in
AlsaModularSynth,
Arts,
Galan,
Gdam,
Glame,
NMEdit,
PD,
Quasimodo,
SpiralSynthModular.
Also we should have an API and a script in the system.
I can set up a project folder to our ftp site, ftp.funet.fi,
for resources (manuals and screenshots of existing systems, research
papers). Coding should happen in some CVS site.
Any comments?
Regards,
Juhana
4:50 p.m.
At 05:53 AM 14/01/2004, Nathaniel Virgo wrote:
I think another great application for such a thing
would be a JACK patch
bay. It would be so much easier to use something like this to connect
apps (and internal ardour connections) than it is at the moment. I always
wanted to write such a thing myself but never really had the time. In
many ways a JACK patch bay would be one of the most demanding applications
for this because it has to handle both many-to-one and one-to-many
connections and JACK graphs can be very complicated, so I would suggest
bearing it in mind while designing it, on the grounds that if it can
handle that it will be able to handle many other things as well. I also
think that having the option of embedding synth GUIs into the graph is
very important.
There already is. Check out http://qjackctl.sourceforge.net.
Luke
--
Luke Yelavich
AudioSlack Founder and head package maintainer
Audio software packaged for the Slackware Linux Distribution
http://www.audioslack.com
luke(a)audioslack.com
9:17 p.m.
On Tue, 2004-01-13 at 11:09, Juhana Sadeharju wrote:
Hello.
I feel we should write a modular synth editor from scratch.
I have checked many existing systems but none is good enough.
The editor would just be the editor. There would not be
anything related to audio processing. Developers could use
the editor in any project, audio or not.
The editor would handle GUIs such as in
AlsaModularSynth,
Arts,
Galan,
Gdam,
Glame,
NMEdit,
PD,
Quasimodo,
SpiralSynthModular.
Also we should have an API and a script in the system.
I can set up a project folder to our ftp site, ftp.funet.fi,
for resources (manuals and screenshots of existing systems, research
papers). Coding should happen in some CVS site.
Any comments?
Regards,
Juhana
(Ironically I've been thinking about this all day during class...)
I can't really tell if you're talking about a modular softsynth (ala ssm
and ams) or an editor for hard synths (Nord modular?), but I definately
think something needs to be done on the "virtual modular (soft) synth"
front. (So I'll just go off on a tangent here)
The way I see it, the existing efforts all fail in one major way:
LADSPA utilisation (well, ssm is getting better here but the polyphony
thing ruins it's potential). We have this nice plugin API and _TONS_ of
plugins that use it, I think we need (I /know/ I need anyway ;) ) a
SIMPLE modular synth app that uses LADSPA plugins (almost) exclusively.
Why have yet another app-specific plugin format? Stupid, stupid.
That's what LADSPA is for. A nice side effect of this app's existance
would be way more nice LADSPA plugins for us all to play with how we
choose. The fact that the existing modular synths have their own
oscillators (and scores of other plugins) in their own formats seems
pretty stupid to me.
I don't think an app like this need be that complicated: all it really
needs to do (in the audio engine) is allow connecting LADSPA plugin
"ports" to other plugins. LADSPA being what it is; that's not such a
difficult task (and most of the code could be borrowed from existing
projects anyway).
(If you think this is just a stupid idea you should probably stop
reading now...)
Criteria I think is important (I actually do use ssm/ams/etc to create
sounds for my music and just to fiddle w/ my keyboard controller (Roland
A-37), so I suppose I count as a "user" this time..):
-- Seperation of UI and backend
I don't think the advantages of this need much explanation. Point being
widget set wars should be avoided. :) But the engine being seperate
definately makes it more useful.
-- Polyphony
SSM is damn near useless because of this (for me anyway). A monophonic
synth is just not a really useful tool when you consider playing it with
a keyboard. Not being able to play chords? No thanks. Polyphony needs
to be changable on the fly too (ams is really annoying in this regard).
-- Subpatches
Things get complicated. Abstraction is good. Pd is the only
environment of the popular Linux ones that does this AFAIK. Plus,
subpatches mean a community can be built up and people can share their
"modules" with others to incorporate into their own creations, etc.
-- Simplicity
Jack in, jack out, LADSPA plugins for pretty juch everything, that's
it. Just a simple audio framework and (seperate) GUI to create modular
synths. Think 'Unix Philosophy' - once again a good thing that needs no
explanation. The only cases where this "everything is a LADSPA plugin"
might not be okay that I can think of is PCM in/out and MIDI in/out.
Would it be possible to create LADSPA plugins to do this (basically a
LADSPA plugin that's an aseq client).. would it be wise? Needs to be
sorted out.. I have mapped out pretty well in my head how to make
LADSPA plugins completely easy to use in this sort of scenario (from a
UI standpoint that is), but I'll spare that for later, assuming anyone
cares.
-- MIDI control
No brainer. Every parameter controllable via MIDI. Similar to ams
which is really cool in this department.
-- Flexibility
This one's a bit abstract I suppose, but every single arrangement of
modules, setting combination, configuration, etc. etc. should be
possible where feasible. Anyone who likes fiddling with modular synths
knows that's pretty much the whole point. This is probably more of a
plugin design decision though (ports, ports, ports), with the app being
so simple.
.... aaaaand I'm spent. Anybody with more ideas/criteria for the
perfect modular synth?
For the record, absolutely no disrespect towards authors of existing
efforts (ams, ssm, both great and certainly have their plusses), I
probably wouldn't have known what a modular synth was if it wasn't for
you guys ;). Gratitude..
(Also, yes, I'm actually a coder, and yes, I'm willing to take this on
(time being limited as it may be).. I'm not one of those self-appointed
open-source-developer-dictators ;) )
Discuss..
-Dave
14 Jan
14 Jan
10:18 a.m.
Hi
--- Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
On Tue, 2004-01-13 at 11:09, Juhana Sadeharju wrote:
> Hello.
>
> I feel we should write a modular synth editor from scratch.
> I have checked many existing systems but none is good enough.
>
> The editor would just be the editor. There would not be
> anything related to audio processing. Developers could use
> the editor in any project, audio or not.
>
> The editor would handle GUIs such as in
> AlsaModularSynth,
> Arts,
> Galan,
> Gdam,
> Glame,
> NMEdit,
> PD,
> Quasimodo,
> SpiralSynthModular.
>
> Also we should have an API and a script in the system.
>
> I can set up a project folder to our ftp site, ftp.funet.fi,
> for resources (manuals and screenshots of existing systems, research
> papers). Coding should happen in some CVS site.
>
> Any comments?
>
> Regards,
> Juhana
I'm chiming in because I've had this kind of thing in the 'planning
stage'
(read: too slack to do anything :) for a fair while.
[...]
I can't really tell if you're talking about a
modular softsynth (ala ssm
and ams) or an editor for hard synths (Nord modular?), but I definately
think something needs to be done on the "virtual modular (soft) synth"
front. (So I'll just go off on a tangent here)
The way I see it, the existing efforts all fail in one major way:
LADSPA utilisation (well, ssm is getting better here but the polyphony
thing ruins it's potential). We have this nice plugin API and _TONS_ of
plugins that use it, I think we need (I /know/ I need anyway ;) ) a
SIMPLE modular synth app that uses LADSPA plugins (almost) exclusively.
I need one too. I've done lots of 'bitwork' in ssm, galan and ams (mostly
ssm)
- a few random noises for miscellaneous purposes :). I've also done a bit of
coding work on the SSM LADSPA plugin (RDF categories, GUI generation).
It's certainly possible to get a virtual studio set up using a combination of
various existing apps with a bit of effort (thanks to JACK). And I'm sure that
if I put the effort to learn it properly, PD would be very close to ideal.
However, the idea of a dedicated, simple modular synth is compelling.
Why have yet another app-specific plugin format?
Stupid, stupid.
That's what LADSPA is for. A nice side effect of this app's existance
would be way more nice LADSPA plugins for us all to play with how we
choose. The fact that the existing modular synths have their own
oscillators (and scores of other plugins) in their own formats seems
pretty stupid to me.
I think the main reason for this (for SSM at least) is firstly that LADSPA
support came after the app was developed, and secondly LADPSA plugins don't
have GUIs - these have to be generated, with limited success. SSM is great in
this regard - the native plugins all have really cool GUIs.
Another issue is that LADSPA plugins cannot be used for sample playback, as
loading samples is impossible unless you stream the data in a la SooperLooper
(http://essej.net/sooperlooper).
I don't think an app like this need be that
complicated: all it really
needs to do (in the audio engine) is allow connecting LADSPA plugin
"ports" to other plugins. LADSPA being what it is; that's not such a
difficult task (and most of the code could be borrowed from existing
projects anyway).
Agreed - at the lowest level it's a directed graph traversed in topological
order - a solved problem. The complicated bit is the interface and additional
functionality (subpatches etc), which is what differentiates existing synths.
(If you think this is just a stupid idea you should
probably stop
reading now...)
Not at all. It's a great idea.
[...]
Anybody with more ideas/criteria for the
perfect modular synth?
OK here I go: From my notes (and fuzzy memory :), what I'd like is a simple cli
program that communicates via some form of IPC. OpenSoundControl (OSC) would
seem to be a good mechanism, as it's quite widely supported and should be
sufficient for all that would be required.
The key here would be to develop an API (I suppose more accurately an ACI -
application Control interface) to cover all intended functionality, which would
include:
* Querying installed LADSPA plugins
Including RDF categorisation
http://plugin.org.uk/lrdf
* Instantiating (adding) plugins and removing them
* Connecting / disconnecting ports
including 'translation' between different port types, e.g.
Control rate <->Audio rate
Range hint scaling (e.g. mapping a +/- 1.0 audio
signal to a logarithmic 5 octave frequency
range) - AlsaModularSynth has a wise approach
of standardising the scales - 1 'Volt' per
octave for frequency etc. much like the old
hardware modulars.
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
* Creation and management of subpatches
A nice feature would be any subpatches automatically
become available as plugins as they are created,
presented alongside vanilla LADSPA ones.
Maybe have a 'publish subpatch' function that lets
you slot in a subpatch into the RDF heirarchy as well.
* Setting up polyphony
Either for the whole graph or just portions of
it - think multiple synths and an effects unit
in a single graph.
* Querying state (e.g. for presentation in a GUI)
Pretty much everything:
Connection state
Names of plugins / ports / subpatches
Inputs and Outputs
Subpatches
...
Interfaces (Graph wiring GUI, Scheme scripting, custom hardware box or
whatever) could then be implemented as independent OSC clients.
I agree with your points, besides the Audio + MIDI I/O - I feel these would be
better implemented as non-plugins. There's also the sample load / save /
playback issue to consider.
For the record, absolutely no disrespect towards
authors of existing
efforts (ams, ssm, both great and certainly have their plusses), I
probably wouldn't have known what a modular synth was if it wasn't for
you guys ;). Gratitude..
Indeed. There's a lot of good ideas in all these apps - it's worth considering
whether efforts could be directed to improving these, rather than starting
totally from scratch. However, this is likely to be more difficult!
(Also, yes, I'm actually a coder, and yes, I'm
willing to take this on
(time being limited as it may be).. I'm not one of those self-appointed
open-source-developer-dictators ;) )
I'm willing to help as well - I've been slacking off on this issue for too
long...
-
Myk
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
12:18 p.m.
On Wed, Jan 14, 2004 at 03:14:59PM +0000, Mike Rawes wrote:
The key here would be to develop an API (I suppose
more accurately an ACI -
application Control interface) to cover all intended functionality, which would
include:
* Querying installed LADSPA plugins
Including RDF categorisation
http://plugin.org.uk/lrdf
* Instantiating (adding) plugins and removing them
* Connecting / disconnecting ports
including 'translation' between different port types, e.g.
Control rate <->Audio rate
Range hint scaling (e.g. mapping a +/- 1.0 audio
signal to a logarithmic 5 octave frequency
range) - AlsaModularSynth has a wise approach
of standardising the scales - 1 'Volt' per
octave for frequency etc. much like the old
hardware modulars.
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
* Creation and management of subpatches
A nice feature would be any subpatches automatically
become available as plugins as they are created,
presented alongside vanilla LADSPA ones.
Maybe have a 'publish subpatch' function that lets
you slot in a subpatch into the RDF heirarchy as well.
* Setting up polyphony
Either for the whole graph or just portions of
it - think multiple synths and an effects unit
in a single graph.
* Querying state (e.g. for presentation in a GUI)
Pretty much everything:
Connection state
Names of plugins / ports / subpatches
Inputs and Outputs
Subpatches
This corresponds quite closely to the long term aims for a second generation
AMS (see my message of a few weeks ago).
As for using LADSPA as the native module format, my first idea when I started
analysing the requirements for a new AMS was exactly that. But there's a lot
of functionality that's hard to implement using the defined LADSPA interfaces.
Some of this could could maybe be added in a backwards compatible way, but
the end result wouldn't be very clean, so I've now all but abandoned this idea.
The problem is not with the lack of a GUI - that would be separate process
anyway, but quite basic things such a checking the number of voices (I proposed
a backwards compatible solution some time ago, but that thread went of into
another direction :-), or just finding out if a port is connected or not.
So any new design will either have only 'static' built-in modules, or define
its own plugin format. I'll probably go for the second option, and will take
the resulting flames with it. LAPSPA support will remain, of course.
--
FA
1:04 p.m.
On Wed, 14 Jan 2004 18:15:24 +0100, Alfons Adriaensen wrote
So any new design will either have only
'static' built-in modules,
or define its own plugin format. I'll probably go for the second
option, and will take the resulting flames with it. LAPSPA support
will remain, of course.
One thing I wanted to do for SSM (although I've had so little time for it over
the last months :( ) is at least have a completely consistent interface for
plugins, whether they are LADSPA or native, the user can't tell the difference
between them. At the moment SSM has a "LADSPA plugin loader-plugin" which
could be hidden by the interface I think.
Looking back, it would have been much better to rely on LADSPA for most of the
audio tasks, but they wern't around when I started AFAIR (and I didn't expect
SSM to be so popular anyway :) ).
As for polyphony in SSM, I intend to at some point write a subpatch plugin
that is a mini version of SSM itself with input/output ports that can
encapsulate sections of the patch - each subpach will have a voice count, and
will be run multiple times and mix down to their outputs. I think this is a
more flexible solution for polyphony than a global approach, as a lot of
control tasks need to (can only?) be done only once.
Yet another thing on my wishlist is to make SSM fully scriptable, with the GUI
just calling script commands. This means you can automate patch building and
do all kinds of powerful stuff - *cough* PD *cough* :]
cheers,
dave
................................. www.pawfal.org/nebogeo
1:46 p.m.
--- Alfons Adriaensen <fons.adriaensen(a)alcatel.be> wrote: > On Wed, Jan 14,
2004 at 03:14:59PM +0000, Mike Rawes wrote:
I see higher level 'instrument' type stuff as being a wrapper outside the
plugin - or more likely, a small graph of plugins - such as a pair of ADSRs, a
DCO and a DCA.
I've 'manually' got polyphony in SSM with a distributor which routes a signal
to successive destinations when triggered, and multiple sets of the same graph
(there's also an example patch with SSM that does this). AMS 1.x does this per
plugin I think, though I haven't studied the code.
The key here would be to develop an API (I
suppose more accurately an ACI -
application Control interface) to cover all intended functionality, which
would
include:
* Querying installed LADSPA plugins
Including RDF categorisation
http://plugin.org.uk/lrdf
* Instantiating (adding) plugins and removing them
* Connecting / disconnecting ports
including 'translation' between different port types, e.g.
Control rate <->Audio rate
Range hint scaling (e.g. mapping a +/- 1.0 audio
signal to a logarithmic 5 octave frequency
range) - AlsaModularSynth has a wise approach
of standardising the scales - 1 'Volt' per
octave for frequency etc. much like the old
hardware modulars.
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
* Creation and management of subpatches
A nice feature would be any subpatches automatically
become available as plugins as they are created,
presented alongside vanilla LADSPA ones.
Maybe have a 'publish subpatch' function that lets
you slot in a subpatch into the RDF heirarchy as well.
* Setting up polyphony
Either for the whole graph or just portions of
it - think multiple synths and an effects unit
in a single graph.
* Querying state (e.g. for presentation in a GUI)
Pretty much everything:
Connection state
Names of plugins / ports / subpatches
Inputs and Outputs
Subpatches
This corresponds quite closely to the long term aims for a second generation
AMS (see my message of a few weeks ago).
As for using LADSPA as the native module format, my first idea when I started
analysing the requirements for a new AMS was exactly that. But there's a lot
of functionality that's hard to implement using the defined LADSPA
interfaces.
Some of this could could maybe be added in a backwards compatible way, but
the end result wouldn't be very clean, so I've now all but abandoned this
idea.
The problem is not with the lack of a GUI - that would be separate process
anyway, but quite basic things such a checking the number of voices (I
proposed
a backwards compatible solution some time ago, but that thread went of into
another direction :-), or just finding out if a port is connected or not.
My plans had all ports connected by default (so they take on the value given
from the hints) - just attach a dummy buffer to the unconnected ports.
So any new design will either have only
'static' built-in modules, or define
its own plugin format. I'll probably go for the second option, and will take
the resulting flames with it. LAPSPA support will remain, of course.
With the exception of samples or other 'blob' data (e.g. IR impulses), I'm
fairly confident that a good modular could be constructed with LADSPA as it is.
I'm prepared to be proved wrong though!
-
Myk
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
4:03 p.m.
On Wed, Jan 14, 2004 at 06:42:58PM +0000, Mike Rawes wrote:
With the exception of samples or other 'blob'
data (e.g. IR impulses), I'm
fairly confident that a good modular could be constructed with LADSPA as it is.
I'm prepared to be proved wrong though!
You're probably right about this. But if I implement all I need using only the
existing LADSPA interfaces, then at least one of the the following would be
true:
- the resulting modules would be technically compliant with the standard, but
completely useless outside the AMS host, as there would be a lot of ports that
carry AMS-specific data.
- or the LADSPA compliant part would only contain *part* of a module (i.e. only
the audio processing), and in that case nothing is gained, as LADSPA is used
only as an internal interface. In fact this would just complicate module
inplementation.
--
Fons
1:49 p.m.
On Wed, 2004-01-14 at 12:15, Alfons Adriaensen wrote:
On Wed, Jan 14, 2004 at 03:14:59PM +0000, Mike Rawes
wrote:
Quick digression about LADSPA in ams: is there a reason exported
control ports on LADSPA plugins don't work (at least for me anyway)? I
realize control ports run at a different rate than the audio, but since
the ports are exported I figured this would be taken care of.
I should probably take this to the ams list, but here's a test case:
MCV Frequency -> Converter (V/Oct to Hz) -> LADSPA Analog Oscillator
Frequency -> Output
(Analog oscillator is I believe from plugin.org.uk, you almost certainly
have it.) Anyway..
Wouldn't number of voices and finding out if a port is connected be
internal to the app? These things can (actually have to) be stored. As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin. Am I missing something here? Besides, since
you've got LADSPA plugins working... well, it must be possible ;).
The key here would be to develop an API (I
suppose more accurately an ACI -
application Control interface) to cover all intended functionality, which would
include:
* Querying installed LADSPA plugins
Including RDF categorisation
http://plugin.org.uk/lrdf
* Instantiating (adding) plugins and removing them
* Connecting / disconnecting ports
including 'translation' between different port types, e.g.
Control rate <->Audio rate
Range hint scaling (e.g. mapping a +/- 1.0 audio
signal to a logarithmic 5 octave frequency
range) - AlsaModularSynth has a wise approach
of standardising the scales - 1 'Volt' per
octave for frequency etc. much like the old
hardware modulars.
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
* Creation and management of subpatches
A nice feature would be any subpatches automatically
become available as plugins as they are created,
presented alongside vanilla LADSPA ones.
Maybe have a 'publish subpatch' function that lets
you slot in a subpatch into the RDF heirarchy as well.
* Setting up polyphony
Either for the whole graph or just portions of
it - think multiple synths and an effects unit
in a single graph.
* Querying state (e.g. for presentation in a GUI)
Pretty much everything:
Connection state
Names of plugins / ports / subpatches
Inputs and Outputs
Subpatches
This corresponds quite closely to the long term aims for a second generation
AMS (see my message of a few weeks ago).
As for using LADSPA as the native module format, my first idea when I started
analysing the requirements for a new AMS was exactly that. But there's a lot
of functionality that's hard to implement using the defined LADSPA interfaces.
Some of this could could maybe be added in a backwards compatible way, but
the end result wouldn't be very clean, so I've now all but abandoned this idea.
The problem is not with the lack of a GUI - that would be separate process
anyway, but quite basic things such a checking the number of voices (I proposed
a backwards compatible solution some time ago, but that thread went of into
another direction :-), or just finding out if a port is connected or not. So any new design will either have only
'static' built-in modules, or define
its own plugin format. I'll probably go for the second option, and will take
the resulting flames with it. LAPSPA support will remain, of course.
After posting my intial message I thought a bit more about AMS.. it's
true, it's so close to what I need modifying it is probably wisest..
despite that most wretched of widget sets QT and that brown color I
can't erase from my mind (I kid! :) ).
Seriously though, since you're obviously familiar with the code, what
would be the relative difficulty of:
- Runtime-configurable polyphony
- LADCCA support
- Fixing above problem with LADSPA control ports, assuming it's not just
my wacky installation
- Configurable whether ports are in the GUI or exported as ports (I
think this one is really important and would increase flexibility a
Whole Lot(TM)) (see my previous message)
- There's a problem with simultaneous MIDI input (ie playing chords)..
some of the notes get left out. Fixing this
But more importantly, if these things get done will they carry on
through the new ams, or is all the work in vain?
4:02 p.m.
On Wed, Jan 14, 2004 at 01:46:52PM -0500, Dave Robillard wrote:
You can change that color, see main.h. As to the widgets, that will comletely
change in the second generation. In fact the GUI will be separate application
that can be replaced without touching the audio code.
Quick digression about LADSPA in ams: is there a
reason exported
control ports on LADSPA plugins don't work (at least for me anyway)? I
realize control ports run at a different rate than the audio, but since
the ports are exported I figured this would be taken care of.
This is one of the areas I never explored (having only recently joined AMS
as a developer). Probably Matthias will be reading this and comment on it.
What I can confirm is that there presently is no 'control' data type in AMS,
all connections use the audio rate buffers.
Wouldn't number of voices and finding out if a
port is connected be
internal to the app? These things can (actually have to) be stored. As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin. Am I missing something here? Besides, since
you've got LADSPA plugins working... well, it must be possible ;).
You can of coourse use plugings in a polyphonic mode, and AMS even implements
a special protocol that enables LADSPA plugins to discover that they are used in
this way (I have some unpublished plugins that actually use this). But this is
not part of the current LADSPA standard. I proposed it some time ago, but when
I mentioned that one use of this would be to let a poly plugin create only one
GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
and how to make them, and the original proposal was lost in the hassle.
There are other reasons why you may want to know that a number of plugin
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices.
Knowing that ports are unconnected can be important if this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,
Some of the functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
So any new
design will either have only 'static' built-in modules, or define
its own plugin format. I'll probably go for the second option, and will take
the resulting flames with it. LAPSPA support will remain, of course.
After posting my intial message I thought a bit more about AMS.. it's
true, it's so close to what I need modifying it is probably wisest..
despite that most wretched of widget sets QT and that brown color I
can't erase from my mind (I kid! :) ). Seriously though, since you're obviously familiar
with the code, what
would be the relative difficulty of:
- Runtime-configurable polyphony
Maybe this could be done, but no promises. It's one the 'features' that I
myself
(as a user) would like to have ASAP.
- LADCCA support
I never looked into LADCCA. This may change after the next LAD conference
(there's a talk on LADCCA scheduled).
- Fixing above problem with LADSPA control ports,
assuming it's not just
my wacky installation
Matthias !?
- Configurable whether ports are in the GUI or
exported as ports (I
think this one is really important and would increase flexibility a
Whole Lot(TM)) (see my previous message)
What sort of 'ports' would that be (except for MIDI, but this is already
possible) ? But maybe I don't understand exactly what you mean.
- There's a problem with simultaneous MIDI input
(ie playing chords)..
some of the notes get left out. Fixing this
There could be a problem if you do not connect the 'gate' ouput of the
MCV. If you have an example that shows the problem (with 'gate' connected),
I'd appreciate if you could send me the .ams file.
But more importantly, if these things get done will
they carry on
through the new ams, or is all the work in vain?
Certainly not in vain, as you request nothing that is not already in the
basic requirements for the new AMS (except LADCCA).But it means twice the
work... :-)
--
Fons
5:20 p.m.
On Wed, Jan 14, 2004 at 09:35:27 +0100, Fons Adriaensen wrote:
We did discuss this briefly, personally I'm against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible).
Wouldn't
number of voices and finding out if a port is connected be
internal to the app? These things can (actually have to) be stored. As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin. Am I missing something here? Besides, since
you've got LADSPA plugins working... well, it must be possible ;).
You can of coourse use plugings in a polyphonic mode, and AMS even implements
a special protocol that enables LADSPA plugins to discover that they are used in
this way (I have some unpublished plugins that actually use this). But this is
not part of the current LADSPA standard. I proposed it some time ago, but when
I mentioned that one use of this would be to let a poly plugin create only one
GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
and how to make them, and the original proposal was lost in the hassle.
There are other reasons why you may want to know that a number of plugin
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices. Knowing that ports are unconnected can be important if
this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,
Agreed, but to be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
Someting like passing the plugin a valid buffer of zeros, with a known
address (that can be queried and compared by the plugin) would be OK,
but would require API extensions.
Some of the functionality I want for the new AMS also
requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.
FWIW I'l note that hardware modular systems dont have metadata streams :)
- Steve
6:24 p.m.
On Wed, 2004-01-14 at 17:16, Steve Harris wrote:
I agree. The S in ladspa is the most important letter in there :).
But, how about we just pretend you didn't even mention the word "UI".
That's what killed the last LADSPA polyphony/misc improvements
discussion.
Anyway, the UIs can't control multiple instances if the simple audio
stuff underneath (ie current LADSPA plugins) can't handle it. _That's_
what we need to look into IMO.
Agreed 100%. Unfortunately, like you said, LADSPA changes. If plugins
are to get more versatile and have more and more control/audio ports,
some mechanism to ignore ports is definately needed.
If I'm just using an oscillator to get a sine wav, it's pretty wasteful
for the plugin to be calculating exponential _and_ liner FM, PWM (pulse
width), and bob knows what else.
I agree, metadata streams = bad bad idea. Unless it can be shown to be
absolutely necessary (which for the record I really doubt). Maybe the
current AMS architechture requires this the way it's written, but I
think it's /possibly/ to write a modular synth that doesn't have it, and
just uses good old LADSPA plugins (ie what I described in my initial
post).
I shouldn't even say "modular synth", because such a program would
definately be an awesome effects rack. Having a jack rack except being
able to string things together however you want is something I think
everyone can appreciate.
There are
other reasons why you may want to know that a number of plugin
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices.
We did discuss this briefly, personally I'm against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible). Knowing that
ports are unconnected can be important if this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,
Agreed, but to be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
Someting like passing the plugin a valid buffer of zeros, with a known
address (that can be queried and compared by the plugin) would be OK,
but would require API extensions. Some of the
functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.
FWIW I'l note that hardware modular systems dont have metadata streams :) - Steve
15 Jan
15 Jan
4:22 a.m.
On Wed, Jan 14, 2004 at 06:22:09 -0500, Dave Robillard wrote:
I agree. The S in ladspa is the most important letter
in there :).
But, how about we just pretend you didn't even mention the word "UI".
That's what killed the last LADSPA polyphony/misc improvements
discussion.
Anyway, the UIs can't control multiple instances if the simple audio
stuff underneath (ie current LADSPA plugins) can't handle it. _That's_
what we need to look into IMO.
Its nothing to do with the plugin - thier control (and uadio for that
matter) inputs can just be bound together. Its just a case of how the UI
is handled by the host.
Agreed 100%. Unfortunately, like you said, LADSPA
changes. If plugins
are to get more versatile and have more and more control/audio ports,
some mechanism to ignore ports is definately needed.
Hmm... disagree. Its not output connections that are imortant, its input
connections. Some plugin naturally have a different behaviour when
different inputs are connected, eg. a reverb with only left connected
becahes differently to one with left and right, but where right is silent.
OTOH it wouldn't hurt.
For reference I was thinking of something like
if (right_in == host->disconneted_input) {
process_mono();
} else {
process_stereo();
}
If I'm just using an oscillator to get a sine wav,
it's pretty wasteful
for the plugin to be calculating exponential _and_ liner FM, PWM (pulse
width), and bob knows what else.
When plugins offer multiple outputs like that its generally becuase one
can be calculated very cheaply from the others. If thats not the case then
the author should provice multiple versions IMNSHO.
I shouldn't even say "modular synth",
because such a program would
definately be an awesome effects rack. Having a jack rack except being
able to string things together however you want is something I think
everyone can appreciate.
Many people (including me) use modular synths primarily as effects racks.
Please dont encourage jack-rack complexity - one of the things that makes
it wonderful is that its so simple.
- Steve
16 Jan
16 Jan
2:26 p.m.
On Thu, 2004-01-15 at 04:19, Steve Harris wrote:
I guess I wasn't clear, but this is exactly what I meant. Definately
input plugins, for both behaviour reasons like you mentioned, and
optimization.. doing calculations on input that isn't even there isn't
very clever.
I suppose I see your point, but
if a mechanism is going to be there for
hinting whether ports are connected or not... why not use it for output
plugins too?
I don't know about you, but when I'm doing synthesis the gkrellm CPU
graph is just a big solid block at 100%... every little bit counts.
Heh, I wasn't advocating eliminating jack-rack from the planet. :)
'Twas just a sidenote, an app like this would be really useful as an
effects "rack".. like stringing guitar pedals together.
Its nothing to do with the plugin - thier control (and
uadio for that
matter) inputs can just be bound together. Its just a case of how the UI
is handled by the host.
Ack! Don't kill this thred by mentioning UI too. :)
Agreed 100%.
Unfortunately, like you said, LADSPA changes. If plugins
are to get more versatile and have more and more control/audio ports,
some mechanism to ignore ports is definately needed.
Hmm... disagree. Its not output connections that are imortant, its input
connections. Some plugin naturally have a different behaviour when
different inputs are connected, eg. a reverb with only left connected
becahes differently to one with left and right, but where right is silent. If I'm
just using an oscillator to get a sine wav, it's pretty wasteful
for the plugin to be calculating exponential _and_ liner FM, PWM (pulse
width), and bob knows what else.
When plugins offer multiple outputs like that its generally becuase one
can be calculated very cheaply from the others. If thats not the case then
the author should provice multiple versions IMNSHO. I
shouldn't even say "modular synth", because such a program would
definately be an awesome effects rack. Having a jack rack except being
able to string things together however you want is something I think
everyone can appreciate.
Many people (including me) use modular synths primarily as effects racks.
Please dont encourage jack-rack complexity - one of the things that makes
it wonderful is that its so simple. - Steve
3:12 p.m.
On Fri, Jan 16, 2004 at 02:23:47 -0500, Dave Robillard wrote:
Sure, though I personally wouldnt use it theres no reason not to have it.
- Steve
When plugins
offer multiple outputs like that its generally becuase one
can be calculated very cheaply from the others. If thats not the case then
the author should provice multiple versions IMNSHO.
I suppose I see your point,
but if a mechanism is going to be there for
hinting whether ports are connected or not... why not use it for output
plugins too?
15 Jan
15 Jan
5:07 a.m.
On Wed, Jan 14, 2004 at 10:16:39PM +0000, Steve Harris wrote:
Indeed. Emumlating analog modular synths has beem a principal aim for Matthias Nagorni,
the original creator of AMS, and this will remain an essential feature in all future
versions. But it's not the only goal, and I see no reasons why AMS should be limited
to what is possible with analog hardware. Anyway, the metadata I plan to use is there
strictly for implementation reasons only, and will functionally invisible to the user.
My conclusion at this point is that ATM the scope of LADSPA is too limited to be able
to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not
meant as
criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by
design.
--
Fons
We did discuss this briefly, personally I'm
against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible).
What I proposed is not a way to 'implement' polyphony -- that is done in the
obvious way by the host creating multiple instances. It is a way to enable
plugins that care about this to discover they are used in a polyphonic way.
Coming back to my original example, if you want a plugin to create its own
GUI without any assistance from the host (and that is ATM the only option with
LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical
windows, one for each voice.
Agreed, but to be acceptable it probably needs to be
transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
And that's a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Some of the
functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.
FWIW I'l note that hardware modular systems dont have metadata streams :)
6:21 a.m.
On Thu, Jan 15, 2004 at 11:04:00 +0100, Alfons Adriaensen wrote:
Obvious, but highly inconvienient for plugin authors. It means you have to
check for the connected state of every input and have some kind of
fallback plan for when its not connected.
Say I have a 2->1 mixer plugin (trivial example). I have to check wether
input 1 and/or input 2 is connected and either have 4 different inner
loops, or alias some of the input buffers to be static zero buffers.
Providing a check algorithm of some kind and requireing the host to always
provide valid LADSPA input buffers is much more convienient.
[metadata streams]
You haven't given an exaple of where user-transparent metadata streams are
needed, but AFAIK none of the existing s/w modular systems use anything
like that.
Coming back to my original example, if you want a
plugin to create its own
GUI without any assistance from the host (and that is ATM the only option with
LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical
windows, one for each voice.
It's not really possible for the plugin to create a UI independently, the
UI control has to be routed via to host to allow automation.
I prefer a model when the host is reponsible for requesting the UI
creation, the UI talks to the host (eg. via OSC) and the host relays the
changes, via th LADSPA API to the plugin.
Agreed, but to
be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
And that's a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention. My conclusion at this point is that ATM the scope of
LADSPA is too limited to be able
to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not
meant as
criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by
design.
Sure, but equally modular synth modules are also very simple - at least
externally. The only thing they can do that LADSPA can't is: have UIs and
detect wether thier inputs are connected. Those are not hard problems to
solve.
FWIW, I dont think its neccesarily important that LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
- Steve
8:56 a.m.
On Thu, Jan 15, 2004 at 11:18:10AM +0000, Steve Harris wrote:
This can be as simple as connecting to your own zero-valued buffer, if
that is what you prefer to do with an unconnected port.
A better solution would have been to have a bit in the hints saying that
this port must always be connected by the host, if necessary to a dummy buffer.
Or even a single bit for the entire plugin. But again it's too late for that.
OTOH, we could introduce the reverse: a bit in the hints requesting the host
*not* to connect a dummy buffer, but instead to set the pointer to NULL if
the port is unconnected. This would be backwards compatible, AFAICS.
It's not really possible for the plugin to create
a UI independently, the
UI control has to be routed via to host to allow automation.
I prefer a model when the host is reponsible for requesting the UI
creation, the UI talks to the host (eg. via OSC) and the host relays the
changes, via th LADSPA API to the plugin.
The best the host can do ATM is to create widgets based on the port hints.
These do not provide any information on how the parameters may be related
or interact. Also, not all parameters types are available.
All this could be in a separate file of course, but I doubt if it's possible
to define a configuration format that captures all possible interactions
and relations that a module designer can think of.
If on the other hand, the 'logic' is in the plugin (as seems natural, since
it's part of the module's functionality), the interfaces are lacking.
They are ATM one way only, and limited to setting parameter values.
And that's
a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Obvious, but highly inconvienient for plugin authors. It means you have to
check for the connected state of every input and have some kind of
fallback plan for when its not connected. FWIW, I dont think its neccesarily important that
LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
I'd agree, but not if the common format is defined to be lowest common
denominator, and dumbed down to make life as simple as possible for simple
cases at the expense of the more general. That's the way MS Word was
designed, and you all know the result :-)
On a more general tone: I think we should be less afraid of complexity
and learning curves. Dumbing down maybe required in order to be popular,
but that's not my aim. And finally, I believe diversity is a Good Thing.
--
FA
9:29 a.m.
On Thu, Jan 15, 2004 at 02:52:45 +0100, Alfons Adriaensen wrote:
This can be as simple as connecting to your own zero-valued buffer, if
that is what you prefer to do with an unconnected port.
Yes, but the 95% of plugins that dont have any special behaviours have to
do this, you have to find a buffer of a suitable length from somewhere
(without calling malloc) and its not back-compatible.
NB the GMPI requirements - which are done from scratch - require that
plugins be able to run without any regard for port connection state.
No, that is not the way word is designed. Word has the most complex
interface and system imaginable, to achieve a very simple task. Think of
all the pontless options that appear in buttons when you start work, most
users dont even know what they do, much less use them. Word makes writing
simple docuents hard (a difficult to use and complex style system with
useless defaults whihc makes it easier to use hand styling), and it makes
writing complex documents... hard.
A counter example is LaTeX, writing simple documents is very easy, and if
you need to lay out complex equations, well you can still do it, but its
difficult (its a difficult problem, other tools that try to simplfy it
do it badly).
Take for example table matrix sharing between oscilator plugins in LADSPA
- LADSPA offers no builtin mechanism for doing that, but its still
possible. It means that all other LADSPA plugins are still simple, and the
handful that need table sharing are slightly more complex than they could
have been if LADSPA supported table sharing. That is a net win.
My philosophy is make the 95% common case easy and the 5% hard case
possible. Optimising for the 5% hard case at the expense of the 95% easy
case is a bad idea. Think SGML v's XML, CORBA v's SOAP, VST v's DirectX
(slightly more ontopic).
DirectX is more capable than VST, but its hardly used in comparison
because the API is such a pain, and its so complex. It makes easy things
hard.
On Thu, Jan 15, 2004 at 11:18:10AM +0000, Steve Harris
wrote:
I was thinking that the UI code would be a piece of software, not just a
description, that would be run my the host - either a seperate binary or a
part of the plugins .so file.
Its important that it communicates through the host though.
It's not really possible for the plugin to
create a UI independently, the
UI control has to be routed via to host to allow automation.
I prefer a model when the host is reponsible for requesting the UI
creation, the UI talks to the host (eg. via OSC) and the host relays the
changes, via th LADSPA API to the plugin.
The best the host can do ATM is to create widgets based on the port hints.
These do not provide any information on how the parameters may be related
or interact. Also, not all parameters types are available.
All this could be in a separate file of course, but I doubt if it's possible
to define a configuration format that captures all possible interactions
and relations that a module designer can think of. And that's a pity. Since all ports in LADSPA are
pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Obvious, but highly inconvienient for plugin authors. It means you have to
check for the connected state of every input and have some kind of
fallback plan for when its not connected. A better solution would have been to have a bit in the
hints saying that
this port must always be connected by the host, if necessary to a dummy buffer.
Or even a single bit for the entire plugin. But again it's too late for that.
OTOH, we could introduce the reverse: a bit in the hints requesting the host
*not* to connect a dummy buffer, but instead to set the pointer to NULL if
the port is unconnected. This would be backwards compatible, AFAICS.
Yes, but why not just have some way of telling if its the dummy buffer?
The plugin might want to be told, but still have a dummy buffer of the
right size available, and the host still has to have a (single) dummy buffer
available for plugins that dont support it. I dont see any reason to pass
NULL.
FWIW, I dont
think its neccesarily important that LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
I'd agree, but not if the common format is defined to be lowest common
denominator, and dumbed down to make life as simple as possible for simple
cases at the expense of the more general. That's the way MS Word was
designed, and you all know the result :-) On a more general tone: I think we should be less
afraid of complexity
and learning curves. Dumbing down maybe required in order to be popular,
but that's not my aim. And finally, I believe diversity is a Good Thing.
I agree about diversity, but disgree totally about the other points. In my
experieince complex systems are generally failures - they rarely offer
anything thats a significant advantage over (comparativly) simple systems,
and modular synth modules are simple systems - if there not then youre
doing something wrong.
- Steve
10:25 a.m.
On Thu, Jan 15, 2004 at 02:26:34PM +0000, Steve Harris wrote:
Because passing NULL is the obvious way to do it, and there is no need to
introduce a new mechanism. And since no existing plugin will request this,
it's perfectly compatible. If you prefer simplicity, why make it more
complex ?
I was thinking that the UI code would be a piece of
software, not just a
description, that would be run my the host - either a seperate binary or a
part of the plugins .so file.
That's a solution, but outside the current LADSPA specs. And the separate
binary would be specific for a particular host.
OTOH, we could
introduce the reverse: a bit in the hints requesting the host
*not* to connect a dummy buffer, but instead to set the pointer to NULL if
the port is unconnected. This would be backwards compatible, AFAICS.
Yes, but why not just have some way of telling if its the dummy buffer? I agree about diversity, but disgree totally about the
other points. In my
experieince complex systems are generally failures - they rarely offer
anything thats a significant advantage over (comparativly) simple systems,
and modular synth modules are simple systems - if there not then youre
doing something wrong.
I'm not advocating complexity for its own sake -- things should be as simple
as they can be, *but not simpler*. Anyway, there is nothing complex in setting
a bit in a constant hints value.
But let's agree to disagree !
--
Fons
10:38 a.m.
On Thu, Jan 15, 2004 at 04:21:29PM +0100, Alfons Adriaensen wrote:
The sperate binary is host neutral, but the .so would have to be host
specific (well, host toolkit specific) to some extent.
Because passing NULL is the obvious way to do it, and there is no need to
introduce a new mechanism. And since no existing plugin will request this,
it's perfectly compatible. If you prefer simplicity, why make it more
complex ?
It doesnt make it more complex. Instead of comparing to NULL you're
comparing to a known constant - the difference is that it makes the plugin
logic, for 95% of plugins, much simpler.
I agree that its a slight deviation from the traditional C cliche, but I
think the advantages are very significant.
No, but theres a lot of comlexity in handling that.
- Steve
I was thinking
that the UI code would be a piece of software, not just a
description, that would be run my the host - either a seperate binary or a
part of the plugins .so file.
That's a solution, but outside the current LADSPA specs. And the separate
binary would be specific for a particular host. OTOH, we could introduce the reverse: a bit in the
hints requesting the host
*not* to connect a dummy buffer, but instead to set the pointer to NULL if
the port is unconnected. This would be backwards compatible, AFAICS.
Yes, but why not just have some way of telling if its the dummy buffer? I agree about
diversity, but disgree totally about the other points. In my
experieince complex systems are generally failures - they rarely offer
anything thats a significant advantage over (comparativly) simple systems,
and modular synth modules are simple systems - if there not then youre
doing something wrong.
I'm not advocating complexity for its own sake -- things should be as simple
as they can be, *but not simpler*. Anyway, there is nothing complex in setting
a bit in a constant hints value.
11:02 a.m.
On Thu, Jan 15, 2004 at 03:35:05PM +0000, Steve Harris wrote:
the difference is that it makes the plugin
logic, for 95% of plugins, much simpler.
I fail to see that. Only plugins that specifically requested NULL pointers
by setting the hint bit have to test for them. The 95% others, including all
existing ones, can just ignore the whole issue, they will always get valid
pointers.
--
FA
11:20 a.m.
On Thu, Jan 15, 2004 at 04:58:26PM +0100, Alfons Adriaensen wrote:
On Thu, Jan 15, 2004 at 03:35:05PM +0000, Steve Harris
wrote:
Yes, OK, maybe its not a significant as I think, I still think it is
still more complex - you introduce a new hint, and the plugin can no
longer assume that all buffer pinters are valid - though it has to
be aware that it might not be.
So I think this would be an acceptable solution for LADSPA, and it
would involve fewer changes to existing hosts than adding refernce
buffers.
- Steve
the difference is that it makes the plugin
logic, for 95% of plugins, much simpler.
I fail to see that. Only plugins that specifically requested NULL pointers
by setting the hint bit have to test for them. The 95% others, including all
existing ones, can just ignore the whole issue, they will always get valid
pointers.
11:41 a.m.
On Thu, Jan 15, 2004 at 04:17:19PM +0000, Steve Harris wrote:
On Thu, Jan 15, 2004 at 04:58:26PM +0100, Alfons
Adriaensen wrote:
I agree. It was not clear at all how the plugin should obtain the dummy
pointer value to compare with -- that would probably require more invasive
changes.
OK, now that we agree :-), I'll leave to you the honour of designating the
new hint bit. If you like I'll add the necessary comments to the header
file and send it for approval this weekend.
--
Fons
On Thu, Jan 15, 2004 at 03:35:05PM +0000, Steve
Harris wrote:
Yes, OK, maybe its not a significant as I think, I still think it is
still more complex - you introduce a new hint, and the plugin can no
longer assume that all buffer pinters are valid - though it has to
be aware that it might not be.
So I think this would be an acceptable solution for LADSPA, and it
would involve fewer changes to existing hosts than adding refernce
buffers. the difference is that it makes the plugin
logic, for 95% of plugins, much simpler.
I fail to see that. Only plugins that specifically requested NULL pointers
by setting the hint bit have to test for them. The 95% others, including all
existing ones, can just ignore the whole issue, they will always get valid
pointers.
12:27 p.m.
On Thu, Jan 15, 2004 at 05:38:04PM +0100, Alfons Adriaensen wrote:
Can we wait until the 1.2 pending changes go through - I think there
more important and I dont want them to get tangled up in the this.
Not all the stakeholders have agreed that disconnected ports are
LADSPA-y enough yet either.
- Steve
So I think
this would be an acceptable solution for LADSPA, and it
would involve fewer changes to existing hosts than adding refernce
buffers.
I agree. It was not clear at all how the plugin should obtain the dummy
pointer value to compare with -- that would probably require more invasive
changes.
OK, now that we agree :-), I'll leave to you the honour of designating the
new hint bit. If you like I'll add the necessary comments to the header
file and send it for approval this weekend. 
16 Jan
16 Jan
9:19 p.m.
New subject: LADSPA 1.2+, Re: [linux-audio-dev] Project: modular synth editor
Steve Harris wrote:
Can we wait until the 1.2 pending changes go through -
I think there
more important and I dont want them to get tangled up in the this.
is there a draft/diff for LADSPA 1.2 i could have a look at? i have no
idea what the changes will be (have been off l-a-d for most of 2003)
and would like to find out.
Not all the stakeholders have agreed that disconnected
ports are
LADSPA-y enough yet either.
nothing of an important stakeholder here, but to me hinting
'accept-null-pointer' per port sounds ok, provided we have enough
spare hint bits.
tim
2:51 p.m.
On Thu, 2004-01-15 at 08:52, Alfons Adriaensen wrote:
On a more general tone: I think we should be less
afraid of complexity
and learning curves. Dumbing down maybe required in order to be popular,
but that's not my aim. And finally, I believe diversity is a Good Thing.
Writing good modular software with simple modules that interact in
well-defines ways is NOT "dumbing down"!
Is UNIX a dumbed down operating system?
8:08 p.m.
On Fri, Jan 16, 2004 at 02:49:05PM -0500, Dave Robillard wrote:
On Thu, 2004-01-15 at 08:52, Alfons Adriaensen wrote:
Nor did I say such a thing.
On a more general tone: I think we should be less
afraid of complexity
and learning curves. Dumbing down maybe required in order to be popular,
but that's not my aim. And finally, I believe diversity is a Good Thing.
Writing good modular software with simple modules that interact in
well-defines ways is NOT "dumbing down"! Is UNIX a dumbed down operating system?
Certainly not, and it provides a good example of what I mean. Unix system
calls are always designed to be as general as possible, even if this means
that that they are more difficult to use than what would be required in 99%
of all cases. Very often you must supply parameters that are not relevant
to your specific call, and you are supposed to check for errors on return
even if they are very improbable. In most cases this complexity is handled
in an 'elegant' way, by using obvious conventions such as a NULL pointer
indicating that you want a sensible default. The consequence is that you are
rarely limited by the UNIX system API - it will normally handle everything
you can imagine. It's this elegant generality that I'm missing a bit in the
way LADSPA is defined.
--
Fons
17 Jan
17 Jan
5:20 a.m.
On Sat, Jan 17, 2004 at 01:32:42 +0100, Fons Adriaensen wrote:
I dont think thats true, if you compare UNIX system calls to thier windows
counterparts I think you'l see that they are actually very simple - often
encapsulating complex behaviour in a simple API. Or, reflecting most of
the system aspects into a single filesystem: that looses a small ammount of
capability (well, makes it harder to do certain things), but the resulting
system is massivly more simple for it, in the general case.
Another example is fork() which has exactly the bare minimum of features,
compared to clone(), which is rarely used (though neccesary in some cases)
and exposes all the tiny details. I would be very unhappy if I had to use
clone() everytime I wanted to fork a process.
Is UNIX a
dumbed down operating system?
Certainly not, and it provides a good example of what I mean. Unix system
calls are always designed to be as general as possible, even if this means
that that they are more difficult to use than what would be required in 99%
of all cases. Very often you must supply parameters that are not relevant indicating that you want a sensible default. The
consequence is that you are
rarely limited by the UNIX system API - it will normally handle everything
you can imagine. It's this elegant generality that I'm missing a bit in the
way LADSPA is defined.
I think it is present FWIW.
- Steve
18 Jan
18 Jan
6:34 p.m.
On Fri, 2004-01-16 at 19:32, Fons Adriaensen wrote:
On Fri, Jan 16, 2004 at 02:49:05PM -0500, Dave
Robillard wrote:
I mean the design of unix from a user perspective, not how the system
calls are designed.
Small little tools that do one thing and communicate via pipes, etc.
The system is actually more powerful because of this simplicity.
On Thu, 2004-01-15 at 08:52, Alfons Adriaensen
wrote:
Nor did I say such a thing.
On a more general tone: I think we should be less
afraid of complexity
and learning curves. Dumbing down maybe required in order to be popular,
but that's not my aim. And finally, I believe diversity is a Good Thing.
Writing good modular software with simple modules that interact in
well-defines ways is NOT "dumbing down"! Is UNIX a dumbed down operating system?
Certainly not, and it provides a good example of what I mean. Unix system
calls are always designed to be as general as possible, [snip]
16 Jan
16 Jan
2:42 p.m.
On Thu, 2004-01-15 at 06:18, Steve Harris wrote:
Sure, but equally modular synth modules are also very
simple - at least
externally. The only thing they can do that LADSPA can't is: have UIs and
detect wether thier inputs are connected. Those are not hard problems to
solve.
Well, I was really trying to kill the LADSPA GUI discussion (just
because it killed the last similar LADSPA thread), but I'll say
something about it:
Not once in my fiddlings with LADSPA plugins in a modular synth have I
said to myself "Damn.. these things need a big spiffy GUI". Honestly, a
bunch of sliders works just fine for me - I don't really see the need
for more. Sure, VSTs that look like shiny audio hardware are nifty...
but who cares?
(I mean, yes it would be nice if LADSPA could do that I guess. But it
can't, and I think it's a completely seperate problem to the modular
synth/polyphony/port connected problems)
FWIW, I dont think its neccesarily important that
LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
Absolutely, but if LADSPA could be that plugin format.. that would be
obviously the best case. Then every audio plugin would be the same
format, which is cool.
GUI stuff aside, are there any compelling reasons to create a new
modular synth plugin API? (LADMSPA doesn't have a very nice ring to it
:) )
- Steve
3:11 p.m.
On Fri, Jan 16, 2004 at 02:39:36PM -0500, Dave Robillard wrote:
I would not like a (to my mind) artificial split between modular synth
plugins and general LADSPA plugins either.
The only thing I'm really missing from the LADSPA specs at the moment is
the availability of 'recorded' streams (so you could implement a sample
player as a LADSPA plugin, or play recorded tracks backward, etc.)
My ideas on this are rather shady, but to me the most "simple" solution
would be, to let the host handle all memory management, loading, etc for
the streams, and to present them to the plugin as an "object" so the
plugin can request a buffer representing part of the stream (so you don't
need all recorded streams in memory, and the reading of files, etc is
out of the plugin's responsibility).
BTW: My apologies for posting these ramblings, if they are inappropriate,
as I'm new to this list.
Joost Diepenmaat.
Not once in my fiddlings with LADSPA plugins in a
modular synth have I
said to myself "Damn.. these things need a big spiffy GUI". Honestly, a
bunch of sliders works just fine for me - I don't really see the need
for more. Sure, VSTs that look like shiny audio hardware are nifty...
but who cares?
I agree in general; the only time this becomes helpful is when plugins
have *lots* of control ports, I think. (disclamer: I've been mostly
using Buzz on win32 for audio use, but the situation is much the same
there - most plugins just let the GUI be generated by the host, and
of those that don't, only a couple actually improve the situation -
actually, the only one I can think of is the default mixer plugin,
which has 16 channels with about 7 controls per channel - that just
too much to represent as a bunch of vertically aligned sliders)
OTOH, my guess is that this *could* be solved by making polophony
explicit, so only some ports get duplicated when the a voice is
added - if a host is aware of this, it could employ some grouping
of controls for the extra voices that takes less space.
FWIW, I dont
think its neccesarily important that LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
Absolutely, but if LADSPA could be that plugin format.. that would be
obviously the best case. Then every audio plugin would be the same
format, which is cool.
3:49 p.m.
On Fri, 2004-01-16 at 15:08, Joost Diepenmaat wrote:
On Fri, Jan 16, 2004 at 02:39:36PM -0500, Dave
Robillard wrote:
This is a good example, but I _REALLY_ don't want to turn this into /yet
another/ endless LADSPA GUI discussion that will come to nothing.
Not once in my fiddlings with LADSPA plugins in a
modular synth have I
said to myself "Damn.. these things need a big spiffy GUI". Honestly, a
bunch of sliders works just fine for me - I don't really see the need
for more. Sure, VSTs that look like shiny audio hardware are nifty...
but who cares?
I agree in general; the only time this becomes helpful is when plugins
have *lots* of control ports, I think. (disclamer: I've been mostly
using Buzz on win32 for audio use, but the situation is much the same
there - most plugins just let the GUI be generated by the host, and
of those that don't, only a couple actually improve the situation -
actually, the only one I can think of is the default mixer plugin,
which has 16 channels with about 7 controls per channel - that just
too much to represent as a bunch of vertically aligned sliders) I would not like a (to my mind) artificial split
between modular synth
plugins and general LADSPA plugins either.
The only thing I'm really missing from the LADSPA specs at the moment is
the availability of 'recorded' streams (so you could implement a sample
player as a LADSPA plugin, or play recorded tracks backward, etc.)
Use a sampler app for this. What's the point of being able to do it in
a LADSPA plugin?
-Dave
4:20 p.m.
On Fri, Jan 16, 2004 at 03:47:07PM -0500, Dave Robillard wrote:
It just bothers me that it's impossible (or at least, unportable) to use
user defined waveforms in LADSPA plugins. Especially since I cannot find
any other "open" and widely supported plugin format that supports this.
Joost.
I would not
like a (to my mind) artificial split between modular synth
plugins and general LADSPA plugins either.
The only thing I'm really missing from the LADSPA specs at the moment is
the availability of 'recorded' streams (so you could implement a sample
player as a LADSPA plugin, or play recorded tracks backward, etc.)
Use a sampler app for this. What's the point of being able to do it in
a LADSPA plugin?
8:08 p.m.
On Fri, Jan 16, 2004 at 09:08:33PM +0100, Joost Diepenmaat wrote:
... most plugins just let the GUI be generated by the
host, and
of those that don't, only a couple actually improve the situation -
actually, the only one I can think of is the default mixer plugin,
which has 16 channels with about 7 controls per channel - that just
too much to represent as a bunch of vertically aligned sliders)
I have to disagree. In many cases these 'automatically generated'
GUIs provide a layout that is quite poor. In my younger days I've
spent lots of time using big multitrack mixing desks. Before
everything went digital and user interfaces could be shared between
channels, these desks had zillions of knobs and buttons. One thing
I learned there is the importance of a good layout. Most 'big name'
manufacturers did this quite well, using subliminal hints of all
sorts to make you unconsciously absorb the logic of the layout in
your mind, thereby allowing you to reach for the right control in
a minimum of time without having to think.
A modular synth that allows complex patches or has complex modules
should IMHO try to have a GUI that has the same qualities.
--
Fons
3:15 p.m.
On Fri, Jan 16, 2004 at 02:39:36 -0500, Dave Robillard wrote:
Not once in my fiddlings with LADSPA plugins in a
modular synth have I
said to myself "Damn.. these things need a big spiffy GUI". Honestly, a
bunch of sliders works just fine for me - I don't really see the need
for more. Sure, VSTs that look like shiny audio hardware are nifty...
but who cares?
Thats more symtom than cause - peopel tend not to build complex plugins
because you make a decent UI for them.
(I mean, yes it would be nice if LADSPA could do that
I guess. But it
can't, and I think it's a completely seperate problem to the modular
synth/polyphony/port connected problems)
Its not that LADSPA cant its just that we havent standardised a protocol.
- Steve
2:31 p.m.
On Thu, 2004-01-15 at 05:04, Alfons Adriaensen wrote:
Indeed. Emumlating analog modular synths has beem a principal aim for Matthias Nagorni,
the original creator of AMS, and this will remain an essential feature in all future
versions. But it's not the only goal, and I see no reasons why AMS should be limited
to what is possible with analog hardware. Anyway, the metadata I plan to use is there
strictly for implementation reasons only, and will functionally invisible to the user.
My conclusion at this point is that ATM the scope of LADSPA is too limited to be able
to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not
meant as
criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by
design.
I don't mean to be a PITA about it, but... why? I realise you don't
think LADSPA is up to the task, but without stating reasons. (My
apologies if you did and I missed them)
On Wed, Jan 14, 2004 at 10:16:39PM +0000, Steve Harris
wrote:
I agree this would be nice/necessary, for optimization purposes. If
you've got 20 oscillators going, there's going to be a whole lot of
redundancy going on. LADSPA GUIs are way outside the scope of this
discussion though.
We did discuss this briefly, personally I'm
against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible).
What I proposed is not a way to 'implement' polyphony -- that is done in the
obvious way by the host creating multiple instances. It is a way to enable
plugins that care about this to discover they are used in a polyphonic way.
Coming back to my original example, if you want a plugin to create its own
GUI without any assistance from the host (and that is ATM the only option with
LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical
windows, one for each voice.
Agreed, but to
be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
And that's a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Some of
the functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.
FWIW I'l note that hardware modular systems dont have metadata streams :)
14 Jan
14 Jan
6:16 p.m.
On Wed, 2004-01-14 at 15:35, Fons Adriaensen wrote:
Why does the plugin care? Granted, some resources could be saved having
a mechanism for the plugins to know they're polyphonic; but I don't
think it's that critical. That seems like an optimization detail to me;
I can't think of a reason polyphony couldn't be properly handled by the
host (like I said before, AMS /already does this/)!
You can change that color, see main.h. As to the widgets, that will comletely
change in the second generation. In fact the GUI will be separate application
that can be replaced without touching the audio code.
I know. I have. :D One of these days I might make it use configurable
and send in a patch, but since AMS doesn't even have a config file that
I know of....
Ditto.
Once you start doing anything remotely complicated, LADCCA just becomes
necessary. With this track I've been fiddling with lately it literally
takes 5-10 minutes just to get the environment properly set up.
Obviously this is a pretty big problem. It's getting better though.
I mean ports on the plugins.. take the LFO plugin for a simple example..
right now, the frequency is a control in the GUI (right click, open the
GUI, and you'll get a slider). It would be nice to have the option of
making it a port, so some other part of the synth could plug into it and
control the frequency of the LFO. So you could, say, make higher notes
have a faster vibrato or whatever. (Okay, not the best example, but you
get what I mean).
I don't remember what I was trying to do that made this really annoying,
but trust me, it'd be nice. :)
No, it was connected. The synth works fine in all aspect, except when
notes are _dead on_ simultaneous. I assumed this was because the
developers don't have a real MIDI controller and never ran into this
problem. (vkeybd probably has sufficient delay between "simultaneous"
notes to avoid the problem)
I'll put something together with a .mid file to show it.
Well.... it appears to me like the "new ams" isn't going to materialize
any time soon; my point was: if these improvements are made to the
current AMS, will they all be thrown away for a totally new codebase, or
is alot of the code going to remain?
For me, priority speaking, the LADSPA control port problem, and
simultaneous MIDI notes (which I assume is trivial) are the most
aggravating problems.
Wouldn't
number of voices and finding out if a port is connected be
internal to the app? These things can (actually have to) be stored. As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin. Am I missing something here? Besides, since
you've got LADSPA plugins working... well, it must be possible ;).
You can of coourse use plugings in a polyphonic mode, and AMS even implements
a special protocol that enables LADSPA plugins to discover that they are used in
this way (I have some unpublished plugins that actually use this). But this is
not part of the current LADSPA standard. I proposed it some time ago, but when
I mentioned that one use of this would be to let a poly plugin create only one
GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
and how to make them, and the original proposal was lost in the hassle. There are other reasons why you may want to know that
a number of plugin
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices.
Agreed, would be nice. But still just an optimization detail. Unless
everyone is willing to start drafting LADSPA v2, it's not really worth
talking about. And somehow I doubt LADSPA is gonna be changed anytime
soon (although these problems/improvements would benefit everyone, not
just a modular synth.... think post processing effects, lots of multiple
plugins running there).
Knowing that ports are unconnected can be important if
this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,
Agreed, this would be a nice thing to have. Not critical (like the
above), but nice.
Some of the functionality I want for the new AMS also
requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
I don't think this is necessary, and just adds uneeded complexity
(especially to plugins, which is a Bad Thing(TM)). I'm not familiar
with the internals of ams all that well yet, but is this really the only
way to accomplish these things? If a plugin is polyphonic, there's one
for each voice. It can just go along munging it's audio all day, it
just has one input. I don't see why the plugin has to care in the
slighest what the engine is doing around in as far as polyphony goes.
(Excepting the above optimizations of course)
So any new design will either have only
'static' built-in modules, or define
its own plugin format. I'll probably go for the second option, and will take
the resulting flames with it. LAPSPA support will remain, of course.
After posting my intial message I thought a bit more about AMS.. it's
true, it's so close to what I need modifying it is probably wisest..
despite that most wretched of widget sets QT and that brown color I
can't erase from my mind (I kid! :) ). Seriously
though, since you're obviously familiar with the code, what
would be the relative difficulty of:
- Runtime-configurable polyphony
Maybe this could be done, but no promises. It's one the 'features' that I
myself
(as a user) would like to have ASAP. - LADCCA
support
I never looked into LADCCA. This may change after the next LAD conference
(there's a talk on LADCCA scheduled). - Fixing above
problem with LADSPA control ports, assuming it's not just
my wacky installation
Matthias !?
- Configurable whether ports are in the GUI or
exported as ports (I
think this one is really important and would increase flexibility a
Whole Lot(TM)) (see my previous message)
What sort of 'ports' would that be (except for MIDI, but this is already
possible) ? But maybe I don't understand exactly what you mean. - There's
a problem with simultaneous MIDI input (ie playing chords)..
some of the notes get left out. Fixing this
There could be a problem if you do not connect the 'gate' ouput of the
MCV. If you have an example that shows the problem (with 'gate' connected),
I'd appreciate if you could send me the .ams file. But more
importantly, if these things get done will they carry on
through the new ams, or is all the work in vain?
Certainly not in vain, as you request nothing that is not already in the
basic requirements for the new AMS (except LADCCA).But it means twice the
work... :-)
15 Jan
15 Jan
4:11 a.m.
On Wed, Jan 14, 2004 at 06:13:29 -0500, Dave Robillard wrote:
I don't think this is necessary, and just adds
uneeded complexity
(especially to plugins, which is a Bad Thing(TM)).
Heh, if I had a quid for every time I've said that in the last 6 months I
could retire a rich man :)
- Steve
7:35 a.m.
On Wed, Jan 14, 2004 at 06:13:29PM -0500, Dave Robillard wrote:
I introduced main.h in 1.7.x as a point where all that sort of things will
be collected. Turning that into a run-time configuration will be the second
step.
OK, that maps to the requirement that almost everything that has a slider
must also be 'voltage-controlled'.
Why does the plugin care? Granted, some resources
could be saved having
a mechanism for the plugins to know they're polyphonic; but I don't
think it's that critical. That seems like an optimization detail to me;
I can't think of a reason polyphony couldn't be properly handled by the
host (like I said before, AMS /already does this/)!
Agreed, would be nice. But still just an optimization
detail. Unless
everyone is willing to start drafting LADSPA v2, it's not really worth
talking about. And somehow I doubt LADSPA is gonna be changed anytime
soon (although these problems/improvements would benefit everyone, not
just a modular synth.... think post processing effects, lots of multiple
plugins running there).
Well, let me make one thing very clear. For me, optimization is *not* a
detail nor something that should be ignored during analysis and taken
care of later. By then it's probably too late. When I design or analyse
anything that's not trivial, efficient implementation is as much a point
to be considered as are functionality and abstraction. I've seen too many
good applications being crippled during their entire lifetime by early
design decisions that ignored this.
I don't think this is necessary, and just adds
uneeded complexity
(especially to plugins, which is a Bad Thing(TM)). I'm not familiar
with the internals of ams all that well yet, but is this really the only
way to accomplish these things?
The metadata I'll use is transparent for the user, it's related only
to implementation.
You can change
that color, see main.h. As to the widgets, that will comletely
change in the second generation. In fact the GUI will be separate application
that can be replaced without touching the audio code.
I know. I have. :D One of these days I might make it use configurable
and send in a patch, but since AMS doesn't even have a config file that
I know of.... Once you start doing anything remotely complicated,
LADCCA just becomes
necessary. With this track I've been fiddling with lately it literally
takes 5-10 minutes just to get the environment properly set up.
Obviously this is a pretty big problem. It's getting better though.
I'll keep that in mind. One remark though: I will be happy to support any
session management system as long as it is general and uses only standard
interfaces. If it requires a particular window manager, desktop or toolset
for example, it will not be supported.
What sort of
'ports' would that be (except for MIDI, but this is already
possible) ? But maybe I don't understand exactly what you mean.
I mean ports on the plugins.. take the LFO plugin for a simple example..
right now, the frequency is a control in the GUI (right click, open the
GUI, and you'll get a slider). It would be nice to have the option of
making it a port, so some other part of the synth could plug into it and
control the frequency of the LFO. So you could, say, make higher notes
have a faster vibrato or whatever. (Okay, not the best example, but you
get what I mean). No, it was connected. The synth works fine in all
aspect, except when
notes are _dead on_ simultaneous. I assumed this was because the
developers don't have a real MIDI controller and never ran into this
problem. (vkeybd probably has sufficient delay between "simultaneous"
notes to avoid the problem)
I'll put something together with a .mid file to show it.
Strange. I'm using AMS in poly mode with a real MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.
Well.... it appears to me like the "new ams"
isn't going to materialize
any time soon; my point was: if these improvements are made to the
current AMS, will they all be thrown away for a totally new codebase, or
is alot of the code going to remain?
Almost all the engine code will be new. Too many things need to change.
--
FA
16 Jan
16 Jan
2:29 p.m.
On Thu, 2004-01-15 at 12:32, Alfons Adriaensen wrote:
To trumpet LADCCA some more :) It's been implemented from the ground up
to be totally UI-independant. Any user interface to the server operates
over TCP sockets. At the moment, there is one readline based interface,
and a GTK based interface is in the pipeline:
http://rose.homeunix.net/~rah/lcc-prototype-2.jpeg
Also worth noting is that many interfaces can be used at the same time,
which along with network transparency will undoubtedly come in handy
when things like firewire, rtsp and perhaps magic come into the fore.
In fact, it's always been in the back of my mind that LADCCA should be
able to manage audio setups not just on a single machine, but many.
Network-wide patching is a distant goal. This was the main reason for
using libuuid for client ids.
Bob
--
Bob Ham <rah(a)bash.sh>
"Discussion without action is just a pressure wave in air."
-- Daniel James
Once you start
doing anything remotely complicated, LADCCA just becomes
necessary. With this track I've been fiddling with lately it literally
takes 5-10 minutes just to get the environment properly set up.
Obviously this is a pretty big problem. It's getting better though.
I'll keep that in mind. One remark though: I will be happy to support any
session management system as long as it is general and uses only standard
interfaces. If it requires a particular window manager, desktop or toolset
for example, it will not be supported. 
22 Jan
22 Jan
7:18 a.m.
New subject: [linux-audio-dev] yo!
I just came up with a copy of w32.beagle in this list. {at least... that's
where it got filtered to. {It may have just been pointed at me... I don't know}}
Norton "auto-ate" the file so I really can't be specific about which message
it
was... it is fairly large {~200k} and should be pretty easy to spot.
Figured folk ought to know... just in case anyone's reading this in windows.
--
Ran out of Carbona. Mom threw out the glue
Ran out of paint and roach spray too.
It's TV's fault why I am this way
Mom and pop wanna put me away
{Ramones}
16 Jan
16 Jan
2:48 p.m.
On Thu, 2004-01-15 at 07:32, Alfons Adriaensen wrote:
I'll just assume you have your reasons. But just because AMS is going
to have metadata doesn't mean some modular synth can't use LADSPA
without doing so.
I suggest looking into LADCCA if you don't know what it is.. it's really
cool, and IMO the next Really Important Thing for linux audio.
OK, that maps to the requirement that almost everything that has a slider
must also be 'voltage-controlled'.
I suppose, yes. Is this a problem? The added flexibility would be
huge.
Pedant. :) That's odd.. I'll put one together early next week and look
into it - no other synth prog I have has the problem, so it's not my
system configuration. I have a feeling this one isn't going to be fun
to root out. (I'll take this to the ams list)
On Wed, Jan 14, 2004 at 06:13:29PM -0500, Dave
Robillard wrote:
I agree.. I just said that because it was said using LADSPA is
impossible for these reasons.. well, it's not impossible. Just missing
some optimizations.
The point is those optimizations can (and hopefully will) be grafted
onto LADSPA in a way that doesn't change things much. The discussion
shouldn't be "these optimizations are missing so LADSPA isn't usable",
it should be "we're missing these needed features in LADSPA, so lets fix
that problem".
Why does the plugin care? Granted, some
resources could be saved having
a mechanism for the plugins to know they're polyphonic; but I don't
think it's that critical. That seems like an optimization detail to me;
I can't think of a reason polyphony couldn't be properly handled by the
host (like I said before, AMS /already does this/)!
Agreed, would be nice. But still just an
optimization detail. Unless
everyone is willing to start drafting LADSPA v2, it's not really worth
talking about. And somehow I doubt LADSPA is gonna be changed anytime
soon (although these problems/improvements would benefit everyone, not
just a modular synth.... think post processing effects, lots of multiple
plugins running there).
Well, let me make one thing very clear. For me, optimization is *not* a
detail nor something that should be ignored during analysis and taken
care of later. By then it's probably too late. When I design or analyse
anything that's not trivial, efficient implementation is as much a point
to be considered as are functionality and abstraction. I've seen too many
good applications being crippled during their entire lifetime by early
design decisions that ignored this. I don't
think this is necessary, and just adds uneeded complexity
(especially to plugins, which is a Bad Thing(TM)). I'm not familiar
with the internals of ams all that well yet, but is this really the only
way to accomplish these things?
The metadata I'll use is transparent for the user, it's related only
to implementation. Once you start
doing anything remotely complicated, LADCCA just becomes
necessary. With this track I've been fiddling with lately it literally
takes 5-10 minutes just to get the environment properly set up.
Obviously this is a pretty big problem. It's getting better though.
I'll keep that in mind. One remark though: I will be happy to support any
session management system as long as it is general and uses only standard
interfaces. If it requires a particular window manager, desktop or toolset
for example, it will not be supported. What sort of 'ports' would that be (except for
MIDI, but this is already
possible) ? But maybe I don't understand exactly what you mean.
I mean ports on the plugins.. take the LFO plugin for a simple example..
right now, the frequency is a control in the GUI (right click, open the
GUI, and you'll get a slider). It would be nice to have the option of
making it a port, so some other part of the synth could plug into it and
control the frequency of the LFO. So you could, say, make higher notes
have a faster vibrato or whatever. (Okay, not the best example, but you
get what I mean). No, it was
connected. The synth works fine in all aspect, except when
notes are _dead on_ simultaneous. I assumed this was because the
developers don't have a real MIDI controller and never ran into this
problem. (vkeybd probably has sufficient delay between "simultaneous"
notes to avoid the problem)
I'll put something together with a .mid file to show it.
Strange. I'm using AMS in poly mode with a real MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.
8:08 p.m.
On Fri, Jan 16, 2004 at 02:46:25PM -0500, Dave Robillard wrote:
Depends on how it's done. If a slider corresponds to a control input, then
one would expect the slider to follow the control voltage if it is connected.
That could mean a *lot* of CPU load if you have hundreds of sliders dancing the
night away. Two solutions: 1. Add the control voltage to the slider value
instead of replacing it, but not all parameters can be 'added' in a way that
makes sense, or 2. eliminate the slider and all other widgets, and turn
each of them into a separate module that can optionally be created and
connected to the control input. That means a completely different GUI concept.
What I wanted to point out here (whithout being pedantic :-) is the following:
MIDI input is looked at once for each process cycle, so everything that happened
during the previous cycle is 'dead on simultaneous' as far as AMS is concerned.
And since AMS surely can hande more than one note-on per cycle, you could be
right in suggesting that this one will be fun to root out...
--
Fons
I'll just assume you have your reasons. But just
because AMS is going
to have metadata doesn't mean some modular synth can't use LADSPA
without doing so.
Nor did I say so. To illustrate this point, let me mention the problem of a
voice controller (VC) in a polyphonic patch. How is the VC to know when a voice
has ended and can be re-allocated to a new note ? This requires some feedback
from (typically) the envelope generators. So either you make this explicit
(a solution I do not dislike, but definitely non-standard), or you use a hidden
data path, and in a modular system that means metadata.
I suggest looking into LADCCA if you don't know
what it is.. it's really
cool, and IMO the next Really Important Thing for linux audio.
Wilco.
OK, that maps
to the requirement that almost everything that has a slider
must also be 'voltage-controlled'.
suppose, yes. Is this a problem? The
added flexibility would be huge. Strange.
I'm using AMS in poly mode with a real MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.
Pedant. :) That's odd.. I'll put one together early next week and look
into it - no other synth prog I have has the problem, so it's not my
system configuration. I have a feeling this one isn't going to be fun
to root out. (I'll take this to the ams list)
17 Jan
17 Jan
5:23 a.m.
On Sat, Jan 17, 2004 at 01:05:34 +0100, Fons Adriaensen wrote:
On Fri, Jan 16, 2004 at 02:46:25PM -0500, Dave
Robillard wrote:
Thats true, but the voice controller is generally part of the host
environment, not a plugin. It would typically be the think wihich is
resonsible for splitting the MIDI data to multiple sub-patches and routing
the CV streams (velocity, aftertouch) appropraitly. The modules within the
sub-patch can be completly ignorant of the voice allocation.
- Steve
I'll just assume you have your reasons. But
just because AMS is going
to have metadata doesn't mean some modular synth can't use LADSPA
without doing so.
Nor did I say so. To illustrate this point, let me mention the problem of a
voice controller (VC) in a polyphonic patch. How is the VC to know when a voice
has ended and can be re-allocated to a new note ? This requires some feedback
from (typically) the envelope generators. So either you make this explicit
(a solution I do not dislike, but definitely non-standard), or you use a hidden
data path, and in a modular system that means metadata.
7:38 a.m.
On Sat, Jan 17, 2004 at 10:20:00AM +0000, Steve Harris wrote:
Thats true, but the voice controller is generally part
of the host
environment, not a plugin. It would typically be the think wihich is
resonsible for splitting the MIDI data to multiple sub-patches and routing
the CV streams (velocity, aftertouch) appropraitly. The modules within the
sub-patch can be completly ignorant of the voice allocation.
Putting the voice controller in the host doesn't solve the problem, as it
still needs info from e.g. the envelope generators. So how will that info
be passed when using LADSPA as the module format ? We could add a hint
saying that a particular output port carries this type of data, but I
wouldn't dare propose such a thing -- in contrast to the 'send NULL pointer
hint' we discussed earlier, this one is far too specific. Or the host could
check for a particular port name -- same problem. Adding some sort of port
type could solve the problem, but that's a major change. It's again that
little bit of generality that's missing.
\begin{aside}
But even this could be added in a backwards-compatible way, for example:
- if hint bit 31 is set, this means that the whole port description is
application specific, with hint bits 16..30 identifying the application,
and bits 0..15 and the other port description items defined by the
application. Application IDs are allocated in the same way as plugin
numbers. It's up to any host to accept a particular ID, or to refuse to
load a plugin it can't handle. All this is probably very un-LADSPA-y :-)
\end{aside}
Anyway, in the new AMS the VC will be a module and preferably a plugin.
Some types of music or application could require a non-standard VC, and I
want the user who needs such a thing to be able to write it and plug it in.
This of course means that the plugin should have access to MIDI data,
and to the file system (e.g. a VC that reads a CSOUND score), and
that creates another interface problem.
Others wil of course arise as the design evoluates, for example things
related to (JACK) transport awareness. So iff I would use LADPSA as the
module format, I could go one of two courses:
- Hijack LADSPA, add all the things I need trying not to break anything,
and present the result as an accomplished fact. I would need lots of
fire protection when that happens, and deserve it.
- Present each and every extension to the LADSPA community, go through
the normal discussion process and hope for the best. This will take lots
of time, could lead to nasty inconsistencies when part of a proposal is
accepted and another part is rejected or amended, and in the end would
mean that my entire desing has to be vetted by this list, since most
functionality will be in the modules. I don't think I would accept that.
Please don't take this as criticism on the fantastic work that you and
others have contributed, but ATM I can't escape the conclusion that the
LADSPA format is too limited to be used as the module format for the synth
I want to write. But I will of course support LADSPA -- there are far
too many nice plugins available, and ignoring this would be just stupid.
--
Fons
3:55 p.m.
On Sat, Jan 17, 2004 at 01:32:17 +0100, Fons Adriaensen wrote:
Putting the voice controller in the host doesn't
solve the problem, as it
still needs info from e.g. the envelope generators. So how will that info
be passed when using LADSPA as the module format ? We could add a hint
saying that a particular output port carries this type of data, but I
wouldn't dare propose such a thing -- in contrast to the 'send NULL pointer
hint' we discussed earlier, this one is far too specific. Or the host could
check for a particular port name -- same problem. Adding some sort of port
type could solve the problem, but that's a major change. It's again that
little bit of generality that's missing.
Hmm... even putting this prediction behaviour in the engine is far too
specific, what if the voice contains a delay line? for something as
versatile as a modular synth I think you have to pick one of the
traditional (and more explicable to users anyway) priority schemes - eg.
lowest/higest note or last note, which dont rely on any special knowledge
of the behaviour of each voice.
I'm guessing that you want to kill voices that are finished? Well, my
guess is that you just can't - not without unexpected things happening.
It can only done (some) softsynths synths because they know the semantics
of thier own voices.
I think the best you can do is some kind of (configurable?) timeout after
the note off event is sent whihc causes the voice to fade out and be
killed.
\begin{aside}
But even this could be added in a backwards-compatible way, for example:
- if hint bit 31 is set, this means that the whole port description is
application specific, with hint bits 16..30 identifying the application,
and bits 0..15 and the other port description items defined by the
application. Application IDs are allocated in the same way as plugin
numbers. It's up to any host to accept a particular ID, or to refuse to
load a plugin it can't handle. All this is probably very un-LADSPA-y :-)
Yes, but "well-known" port labels are very ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but it
is a useful convention.
We could define a meta-convention - something like: if the port label
begines with an _ then it should not generally be shown to users (unless
the app knows what its for and wants to expose it) as they wont be able to
do anything useful with it.
- Steve
7:12 p.m.
Steve Harris wrote:
[...] "well-known" port labels are very
ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but it
is a useful convention.
We could define a meta-convention - something like: if the port label
begines with an _ then it should not generally be shown to users (unless
the app knows what its for and wants to expose it) as they wont be able to
do anything useful with it.
i like this idea a lot. looks simple, versatile and elegant to me.
tim
7:51 p.m.
On Sat, Jan 17, 2004 at 08:52:29PM +0000, Steve Harris wrote:
Hmm... even putting this prediction behaviour in the
engine is far too
specific, what if the voice contains a delay line? for something as
versatile as a modular synth I think you have to pick one of the
traditional (and more explicable to users anyway) priority schemes - eg.
lowest/higest note or last note, which dont rely on any special knowledge
of the behaviour of each voice.
It's not done by the engine. *All* modules have the option to 'lock' a voice,
protecting it from being re-used for a new note. The logical OR of all these
locks is fed back to the voice controller, which has the option to use
this info or to ignore it. In most cases, the envelope generator that controls
the voice gain will be all that's required. Any linear and stationary
operation (delay, resonant filtering, reverb) that follows the VCA can be
ignored -- it will just add the new note to the tail of the previous one.
(stationary in this context means: not dependent on events from the VC).
I'm guessing that you want to kill voices that are
finished? Well, my
guess is that you just can't - not without unexpected things happening.
It can only done (some) softsynths synths because they know the semantics
of thier own voices.
No, killing finished voices is not the primary objective. Also, the standard
VC does not really need this info -- it's only used to resolve conflicts
in special cases. The VC I've been testing recently works as follows:
- if there is no 'lock' feedback, the voice that has the 'oldest'
note-off
is re-used. If all voices are 'on', the new note is discarded, or optionally,
the voice with the oldest note-on is re-used.
- if the feedback is used, the VC first checks if there is any 'free' voice,
i.e. one that is not locked. If there is none, the new note is discarded,
or optionally, the previous rule is used.
(and if there's still a problem after all this, you *definitely* need more
voices :-)
The first rule is really the default, unless you enable the lock feedback
feature. That's why I play with the idea of implementing this feedback as
an explicit control connection instead of metadata, to be used only when
necessary.
This may happen for some 'off-mainstream' types of music, if the oldest note
is not necessarily the one you'd want to replace, or if someone writes some
weird instrument-specific VC (e.g.for a sitar-like instrument).
Anyway, the modules that want to generate locks can use whatever criterion
they choose - it's really a general purpose mechanism allowing any module
in a patch to protect an existing voice from being killed by the VC. This
enables you to bypass MIDI's rather primitive voice model that is based on
note numbers only. There are some other special features in the VC, available
only if you do not use MIDI, such as explicit voice assignment. Using this,
you can start a new note 'in the context of' a specified existing one, as in
CSOUND's tie-in feature.
Yes, but "well-known" port labels are very
ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but it
is a useful convention.
What is this latency control port ?
We could define a meta-convention - something like: if
the port label
begines with an _ then it should not generally be shown to users (unless
the app knows what its for and wants to expose it) as they wont be able to
do anything useful with it.
A nice idea ! Even better would be '_app_port' where app is the application
that this port is meant for. Or OSC style: 'app/port'.
The problem of MIDI, transport, xxx.., data remains of course, unless we agree
that the application specific prefix implies a licence to override the default
float* type. Another remaining problem is that LADSPA has no callbacks from the
plugin to the host, unless we agree that an app-specific port can be used to
pass function pointers :-) :-)
But... if I'd use this approach, the resulting modules would be technically
compliant LADSPA plugins, but probably be useless outside JAMS (that's the new
name - the J stands for JACK). One could ask what's the point in that case.
But I'll keep this idea in mind, it *is* nice.
--
Fons
18 Jan
18 Jan
7:02 p.m.
On Sat, 2004-01-17 at 19:45, Fons Adriaensen wrote:
Ack. Speaking as a musician and not a hacker for a moment, I don't
think a new note should ever, ever, ever be discarded!
But you did say optionally... I just had to say that. :) Reusing the
oldest voice should definitely be the default behaviour.
-Dave
I'm
guessing that you want to kill voices that are finished? Well, my
guess is that you just can't - not without unexpected things happening.
It can only done (some) softsynths synths because they know the semantics
of thier own voices.
No, killing finished voices is not the primary objective. Also, the standard
VC does not really need this info -- it's only used to resolve conflicts
in special cases. The VC I've been testing recently works as follows:
- if there is no 'lock' feedback, the voice that has the 'oldest'
note-off
is re-used. If all voices are 'on', the new note is discarded, or optionally,
the voice with the oldest note-on is re-used.
- if the feedback is used, the VC first checks if there is any 'free' voice,
i.e. one that is not locked. If there is none, the new note is discarded,
or optionally, the previous rule is used.
(and if there's still a problem after all this, you *definitely* need more
voices :-)
9:26 p.m.
On Sun, Jan 18, 2004 at 07:00:19PM -0500, Dave Robillard wrote:
Ack. Speaking as a musician and not a hacker for a
moment, I don't
think a new note should ever, ever, ever be discarded!
It's the simplest way to tell the user that (s)he needs more voices :-)
But you did say optionally... I just had to say that.
:) Reusing the
oldest voice should definitely be the default behaviour.
Agreed 100%
--
FA
19 Jan
19 Jan
1:24 a.m.
For what it is worth, some synths employ a lowest volume algorithm instead
of least recently used. Sometimes a voice may be sounding even if it is the
oldest and strange voice stealing effects can be heard (we have all heard
it). This is of course based pon and tied to an output envelope generator of
some type. Stealing the softest signal is much less noticable but much
harder to implement.
-----Original Message-----
From: linux-audio-dev-bounces(a)music.columbia.edu
[mailto:linux-audio-dev-bounces@music.columbia.edu] On Behalf Of Fons
Adriaensen
Sent: Sunday, January 18, 2004 6:20 PM
To: The Linux Audio Developers' Mailing List
Subject: Re: [linux-audio-dev] Project: modular synth editor
On Sun, Jan 18, 2004 at 07:00:19PM -0500, Dave Robillard wrote:
Ack. Speaking as a musician and not a hacker for a
moment, I don't
think a new note should ever, ever, ever be discarded!
It's the simplest way to tell the user that (s)he needs more voices :-)
But you did say optionally... I just had to say that.
:) Reusing the
oldest voice should definitely be the default behaviour.
Agreed 100%
--
FA
4:41 a.m.
On Sun, Jan 18, 2004 at 10:21:23PM -0800, Brad Arant wrote:
For what it is worth, some synths employ a lowest
volume algorithm instead
of least recently used. Sometimes a voice may be sounding even if it is the
oldest and strange voice stealing effects can be heard (we have all heard
it). This is of course based pon and tied to an output envelope generator of
some type. Stealing the softest signal is much less noticable but much
harder to implement.
Its not just fed off the envelope generator, its much more complex than
that I think (I referred to it earlier), that technique cant really be
used in modular systems as you have no way of predicting what the
behaviour of the voice is, or what the user is using the envelope modules
for.
- Steve
18 Jan
18 Jan
3:09 a.m.
On Sat, 17 Jan 2004 20:52:29 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
[...]
Yes, but "well-known" port labels are very
ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but
it is a useful convention.
We could define a meta-convention - something like: if the port label
begines with an _ then it should not generally be shown to users
(unless the app knows what its for and wants to expose it) as they
wont be able to do anything useful with it.
Nice idea (having certain ports hidden from user) - but wouldn't it be
better as a hint, for consistency with the rest of LADSPA?
-
Myk
6:34 a.m.
On Sun, Jan 18, 2004 at 08:07:21 +0000, Mike Rawes wrote:
Er, yes! Good catch, wasnt thinking straight.
A useful extension to this could be that too adjacent 'hidden' ports with
the same name should be connected.
Eg. if you have a plugin with a hidden 'sync' port output connected to a
plugin with a hidden 'sync' input port they should be connected by the
host.
- Steve
Yes, but
"well-known" port labels are very ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but
it is a useful convention.
We could define a meta-convention - something like: if the port label
begines with an _ then it should not generally be shown to users
(unless the app knows what its for and wants to expose it) as they
wont be able to do anything useful with it.
Nice idea (having certain ports hidden from user) - but wouldn't it be
better as a hint, for consistency with the rest of LADSPA?
7:04 p.m.
On Sun, 2004-01-18 at 06:31, Steve Harris wrote:
On Sun, Jan 18, 2004 at 08:07:21 +0000, Mike Rawes
wrote:
Er, yes! Good catch, wasnt thinking straight.
A useful extension to this could be that too adjacent 'hidden' ports with
the same name should be connected.
Eg. if you have a plugin with a hidden 'sync' port output connected to a
plugin with a hidden 'sync' input port they should be connected by the
host.
- Steve
For the record, the idea of hosts automagically connecting things seems
a little sketchy to me...
-Dave
Yes, but
"well-known" port labels are very ladspa-y. eg. the latency
control out port, its not in the spec and it doesnt hurt any apps, but
it is a useful convention.
We could define a meta-convention - something like: if the port label
begines with an _ then it should not generally be shown to users
(unless the app knows what its for and wants to expose it) as they
wont be able to do anything useful with it.
Nice idea (having certain ports hidden from user) - but wouldn't it be
better as a hint, for consistency with the rest of LADSPA?
19 Jan
19 Jan
5:51 a.m.
On Sun, Jan 18, 2004 at 07:01:54 -0500, Dave Robillard wrote:
Yes, I thought I had a use case for it, but in retrospec its just hard to
get right.
- Steve
A useful
extension to this could be that too adjacent 'hidden' ports with
the same name should be connected.
Eg. if you have a plugin with a hidden 'sync' port output connected to a
plugin with a hidden 'sync' input port they should be connected by the
host.
For the record, the idea of hosts automagically connecting things seems
a little sketchy to me...
18 Jan
18 Jan
6:52 p.m.
On Sat, 2004-01-17 at 07:32, Fons Adriaensen wrote:
On Sat, Jan 17, 2004 at 10:20:00AM +0000, Steve Harris
wrote:
Well, regardless of what the voice does after note release, the voice
you want to 'take over' is /probably/ the one with the oldest note-off.
I actually implemented an (un-released) quasi-polyphonic MIDI plugin for
SSM that worked like this, and it was fine (and I played alot of keys on
it). I can't really think of a case where this isn't sufficient.
Maybe if you had a synth that split notes, and lower notes had really
really long envelopes, but higher notes were 'plinkey', but come on.
Thats true, but the voice controller is generally
part of the host
environment, not a plugin. It would typically be the think wihich is
resonsible for splitting the MIDI data to multiple sub-patches and routing
the CV streams (velocity, aftertouch) appropraitly. The modules within the
sub-patch can be completly ignorant of the voice allocation.
Putting the voice controller in the host doesn't solve the problem, as it
still needs info from e.g. the envelope generators. So how will that info
be passed when using LADSPA as the module format ? We could add a hint
saying that a particular output port carries this type of data, but I
wouldn't dare propose such a thing -- in contrast to the 'send NULL pointer
hint' we discussed earlier, this one is far too specific. Or the host could
check for a particular port name -- same problem. Adding some sort of port
type could solve the problem, but that's a major change. It's again that
little bit of generality that's missing. Anyway, in the new AMS the VC will be a module and
preferably a plugin.
Some types of music or application could require a non-standard VC, and I
want the user who needs such a thing to be able to write it and plug it in.
This of course means that the plugin should have access to MIDI data,
and to the file system (e.g. a VC that reads a CSOUND score), and
that creates another interface problem.
I think pretty much everyone agrees that one or two things in a synth
can't be LADSPA plugins.. basically all the input/output stuff you
mentioned.
I'm saying all sound generating/modifying modules could be. I agree
that making a MIDI-input LADSPA plugin is probably a stupid thing to do!
8:47 p.m.
On Sun, Jan 18, 2004 at 06:50:19PM -0500, Dave Robillard wrote:
Well, regardless of what the voice does after note
release, the voice
you want to 'take over' is /probably/ the one with the oldest note-off.
I actually implemented an (un-released) quasi-polyphonic MIDI plugin for
SSM that worked like this, and it was fine (and I played alot of keys on
it). I can't really think of a case where this isn't sufficient.
For most (99%) types of music/instrument, that will work perfectly. But I
can easily imagine situations were this will break down.
Maybe if you had a synth that split notes, and lower
notes had really
really long envelopes, but higher notes were 'plinkey', but come on.
Lower notes having a longer release is quite natural actually. But I was
really thinking about off-mainstream types of music in this context.
I think pretty much everyone agrees that one or two
things in a synth
can't be LADSPA plugins.. basically all the input/output stuff you
mentioned.
Well, they *can* be. There's nothing that prevents a LADSPA plugin from
creating a new thread for things that can't be done in the process call.
So a LADSPA plugin that e.g. plays back samples is certainly possible.
But then either the host isn't aware of what this plugin is doing, or you
have to abuse ports to pass things such as alsa sequencer handles, port
numbers or file names.
I'm saying all sound generating/modifying modules
could be.
Yes and no. The sound processing part can be, but a module needs some
other components. There's also the data required to manage connections,
polyphony, and maybe other things. The object-oriented, C++ way to write
such a system is to create a base class that takes care of all this, and
define a module as anything you like as long as it derives from that
base class. That means that everything a module cq. plugin needs is
*inside* the module cq. plugin, and the only per-module data that is
kept by the host is one base class pointer per module. The current AMS
is built like this. For example the processing graph traversal is not
an algorithm implemented in the engine (as it is e.g. in JACK), it is
just the result of the engine calling all 'terminal' modules (those that
have no outputs). All the rest is done by a recursion implemented in the
base class. I like this architecture, and will need some strong arguments
in order to change it.
Now if you say module == LADSPA plugin, that would mean that
- either you abandon that architecture, put the sound processing part
into the LADSPA part and let the host add the base_class functionality
for each module that is loaded,
- or you abuse the LADSPA ports to implement interfaces they were never
meant for, with the result that you have a 'compliant' plugin that will
be useless outside the host it was designed for.
--
Fons
9:06 p.m.
On Sun, 2004-01-18 at 20:40, Fons Adriaensen wrote:
Well, from the code perspective, the modules themselves will have to be
wrapped with something, yes. I was talking about from the user
perspective. Basically, you "load a LADSPA module" and not some other
crazy format.
So all the audio stuff would be just a plain old LADSPA plugin (which is
a good thing - we've certainly shown LADSPA is capable of this) and
anything else is just a part of your wrapper code (which should be the
same for every plugin thus doesn't need to be stored on disk)
On Sun, Jan 18, 2004 at 06:50:19PM -0500, Dave
Robillard wrote:
You can probably imagine situations where trying to determine is a voice
is "done" (AMS-style) with metadata streams will break down too. ;)
Well, regardless of what the voice does after
note release, the voice
you want to 'take over' is /probably/ the one with the oldest note-off.
I actually implemented an (un-released) quasi-polyphonic MIDI plugin for
SSM that worked like this, and it was fine (and I played alot of keys on
it). I can't really think of a case where this isn't sufficient.
For most (99%) types of music/instrument, that will work perfectly. But I
can easily imagine situations were this will break down. I'm saying
all sound generating/modifying modules could be.
Yes and no. The sound processing part can be, but a module needs some
other components. There's also the data required to manage connections,
polyphony, and maybe other things. The object-oriented, C++ way to write
such a system is to create a base class that takes care of all this, and
define a module as anything you like as long as it derives from that
base class. That means that everything a module cq. plugin needs is
*inside* the module cq. plugin, [snip]
Now if you say module == LADSPA plugin, that would mean that
- either you abandon that architecture, put the sound processing part
into the LADSPA part and let the host add the base_class functionality
for each module that is loaded
Doesn't sound like a bad idea to me, unless I misunderstand you.
Essentially you have a "module" class that contains a LADSPA plugin.
The host itself will indeed take care of connections and whatnot.
I say putting "who I'm connected to" and information like that in the
plugin is a bad design decision, LADSPA or not. Store that in the
patch.
-Dave
19 Jan
19 Jan
4:37 a.m.
On Mon, Jan 19, 2004 at 02:40:53AM +0100, Fons Adriaensen wrote:
Well, they *can* be. There's nothing that prevents
a LADSPA plugin from
creating a new thread for things that can't be done in the process call.
So a LADSPA plugin that e.g. plays back samples is certainly possible.
But then either the host isn't aware of what this plugin is doing, or you
have to abuse ports to pass things such as alsa sequencer handles, port
numbers or file names.
Or use non-LADSPA i/o - there are few situations where thats sensible, but
if the non LADSPA i/o is suitable general (eg. OSC) and the plugin bevaves
itsself without the non-LADSPA stuff then that may be a good idea.
Now if you say module == LADSPA plugin, that would
mean that
- either you abandon that architecture, put the sound processing part
into the LADSPA part and let the host add the base_class functionality
for each module that is loaded,
- or you abuse the LADSPA ports to implement interfaces they were never
meant for, with the result that you have a 'compliant' plugin that will
be useless outside the host it was designed for.
Again you can just use non-LADSPA i/o, especially if the plugins are
really internal to the host and not exported, sounds like an odd thing to
do, but if it makes your code cleaner or simpler then its a good idea,
right?
- Steve
4:32 a.m.
On Sun, Jan 18, 2004 at 06:50:19PM -0500, Dave Robillard wrote:
Well, regardless of what the voice does after note
release, the voice
you want to 'take over' is /probably/ the one with the oldest note-off.
Yes, the problem is when there are no note offs yet. In hardware,
generally you discard the voice with the lowest or highest pitch (picked
at design time).
- Steve
10:14 p.m.
Hi!
Regarding recycling of voices ..
I use four ques:
1) Voices that are off and has silenced. These voices are always safe to
assign. If this que is empty then I'll look for ...
2) Voices that are off but still running. Pick the oldest one if any,
else try ...
3) Voices that are held. They are off but still running in their "on
state" because the hold-pedal is down. If this que is also empty, then
the only thing left to do is ...
4) Pick the oldest voice in the running que, assuming that the music
breaks completely if the rythm gets lost.
cheers // Jens M Andreasen
On mån, 2004-01-19 at 10:29, Steve Harris wrote:
On Sun, Jan 18, 2004 at 06:50:19PM -0500, Dave
Robillard wrote:
Well, regardless of what the voice does after
note release, the voice
you want to 'take over' is /probably/ the one with the oldest note-off.
Yes, the problem is when there are no note offs yet. In hardware,
generally you discard the voice with the lowest or highest pitch (picked
at design time).
- Steve
18 Jan
18 Jan
6:33 p.m.
On Fri, 2004-01-16 at 19:05, Fons Adriaensen wrote:
Depends on how it's done. If a slider corresponds to a control input, then
one would expect the slider to follow the control voltage if it is connected.
That could mean a *lot* of CPU load if you have hundreds of sliders dancing the
night away. Two solutions: 1. Add the control voltage to the slider value
instead of replacing it, but not all parameters can be 'added' in a way that
makes sense, or 2. eliminate the slider and all other widgets, and turn
each of them into a separate module that can optionally be created and
connected to the control input. That means a completely different GUI concept.
Oh yeah, the sliders still responding to input is definately not what I
was thinking. It's an 'or' thing.. slider _or_ control port. SSM does
this kinda thing come to think of it, if you plug into the port (all are
there by default), the control disappears.
What I wanted to point out here (whithout being pedantic :-) is the following:
MIDI input is looked at once for each process cycle, so everything that happened
during the previous cycle is 'dead on simultaneous' as far as AMS is concerned.
And since AMS surely can hande more than one note-on per cycle, you could be
right in suggesting that this one will be fun to root out...
Oh yay. well, I guess no more discussion about this one is possible
without a test/case and/or looking at the code.
On Fri, Jan 16, 2004 at 02:46:25PM -0500, Dave
Robillard wrote:
Good example. I'll grind away at it in my head over the next few days
and see what happens. :) I'm thinking voice allocation could be handled
without really caring what each voice is actually doing at the moment
(it's like a scheduling problem really), but more on that later.
I'll just assume you have your reasons. But
just because AMS is going
to have metadata doesn't mean some modular synth can't use LADSPA
without doing so.
Nor did I say so. To illustrate this point, let me mention the problem of a
voice controller (VC) in a polyphonic patch. How is the VC to know when a voice
has ended and can be re-allocated to a new note ? This requires some feedback
from (typically) the envelope generators. So either you make this explicit
(a solution I do not dislike, but definitely non-standard), or you use a hidden
data path, and in a modular system that means metadata. OK, that maps to the requirement that almost
everything that has a slider
must also be 'voltage-controlled'.
suppose, yes. Is this a problem? The
added flexibility would be huge. Strange. I'm using AMS in poly mode with a real
MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.
Pedant. :) That's odd.. I'll put one together early next week and look
into it - no other synth prog I have has the problem, so it's not my
system configuration. I have a feeling this one isn't going to be fun
to root out. (I'll take this to the ams list) 
15 Jan
15 Jan
10:44 a.m.
On Wed, 14 Jan 2004, Dave Robillard wrote:
Quick digression about LADSPA in ams: is there a
reason exported
For a solution and statement as to the future of ams see below...
control ports on LADSPA plugins don't work (at
least for me anyway)? I
realize control ports run at a different rate than the audio, but since
the ports are exported I figured this would be taken care of.
I should probably take this to the ams list, but here's a test case:
MCV Frequency -> Converter (V/Oct to Hz) -> LADSPA Analog Oscillator
Frequency -> Output
(Analog oscillator is I believe from plugin.org.uk, you almost certainly
have it.) Anyway..
I just checked it out. The problem is solved by choosing the right
conversion mode in the converter module (V/Octave --> 0..1, 1=rate/2).
So it seems like the exported LADSPA control ports do work. Note that
the voltages of the GUI slider and the exported port are added, therefore
you need to set the Frequency slider to 0 in your case.
After posting my intial message I thought a bit more
about AMS.. it's
true, it's so close to what I need modifying it is probably wisest..
[...]
despite that most wretched of widget sets QT and that
brown color I
can't erase from my mind (I kid! :) ).
[...]
Before giving a statement about the past, present and future of ams, I'd
like to mention that Fons has made the colors configurable in main.h,
therefore you are invited to come up with an alternate color scheme ;-)
Now about history and future of ams and why I recommend to rewrite it
from scratch:
My intention behind ams was to implement a simple softsynth with full
MIDI control that is easily operated so that average computer users
can immediately have fun with it. It was more meant to form a demo
for sliders controlled via ALSA MIDI sequencer than a project of the size
that it has now taken. In the beginning I could not even dream of the
sound quality that Fons has brought to the project through his LADSPA plugins.
The current ams seems to have reached it's goal: The current issue of
german Keyboards publishes a 2 page article on ams and linux audio
(written by me) and also 9 MP3s on their download page (www.keyboards.de,
enter 402124 in the Web+ field to access them). So ams makes "mainstream"
audio people aware of Linux software synthesis. BTW the article has also
large link box with pointers to Dave's page, some projects and the LAD page.
Many useful proposals (e.g. polyphony change at runtime, distinction
between control and audio ports so that control data can behandled at
1/16 audio rate which improves speed a lot, distict audio and gui part)
can not easily be realized within the current design. Moreover at least
a part of the source has been written quite in a hurry so that it is not
very clean.
A rewrite does not at all mean that the effort which has gone into ams is
wasted. One can learn from ams and maybe even copy some code from it.
However I would suggest to envisage a larger scale project now in the way
that Fons has suggested.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
16 Jan
16 Jan
3:21 p.m.
On Thu, 2004-01-15 at 10:41, Matthias Nagorni wrote:
I just checked it out. The problem is solved by
choosing the right
conversion mode in the converter module (V/Octave --> 0..1, 1=rate/2).
So it seems like the exported LADSPA control ports do work. Note that
the voltages of the GUI slider and the exported port are added, therefore
you need to set the Frequency slider to 0 in your case.
I've tried all three and none work, but on a conceptual basis.. the
plugin wants Hz, not 0-1.
Many useful proposals (e.g. polyphony change at
runtime, distinction
between control and audio ports so that control data can behandled at
1/16 audio rate which improves speed a lot, distict audio and gui part)
can not easily be realized within the current design. Moreover at least
a part of the source has been written quite in a hurry so that it is not
very clean.
A rewrite does not at all mean that the effort which has gone into ams is
wasted. One can learn from ams and maybe even copy some code from it.
However I would suggest to envisage a larger scale project now in the way
that Fons has suggested.
Matthias
That's basically what I was wondering/looking for. Of course, (to be
the pedant) my view for this project is "larger scale" in scope and
usefullness perhaps, but not actual project size.
14 Jan
14 Jan
1:06 p.m.
I think the main reason for this (for SSM at least) is
firstly that LADSPA
support came after the app was developed, and secondly LADPSA plugins don't
have GUIs - these have to be generated, with limited success. SSM is great in
this regard - the native plugins all have really cool GUIs.
Rather than having GUIs to control plugins, I was thinking ports would
be used for the most part.. real analog modulars don't have nifty GUIs
:). The GUI problem can be solved pretty well with a slightly more
advanced version of what SSM is doing (in CVS) right now... I havn't
really seen any LADSPA plugins that need more than a bunch of
sliders/knobs.
The ideas ams/ssm have used are pretty good, but I would add the
capability of choosing on an individual control basis whether the
control was in the GUI, or exported as a port. This is definately
something severely limiting about ams for me right now... (sure, you can
use MIDI out to get around it, but ew).
Another issue is that LADSPA plugins cannot be used
for sample playback, as
loading samples is impossible unless you stream the data in a la SooperLooper
(http://essej.net/sooperlooper).
This is where the simplicity comes in.. we're not making a sampler :).
Use an external sampler, if you want the audio in the synth, bring it in
as audio. I really think the modularity of the, *ahem* "Linux Audio
Architechture" should be exploited fully.
Something like:
Keyboard --(MIDI)--> Sampler --(JACK)--> Synth --(Jack)--> Output
And you could also of course run the midi into the synth as well to mix
sampled and synth sounds in any way you choose. A dedicated sampler
prog is going to be a heck of alot better sampler than some little
plugin in a modular synth, might as well utilize it. (Plus you could
use drum machines like hydrogen, or whatever you please as an audio
source.. including real-time live audio from a mic or instrument..)
I don't
think an app like this need be that complicated: all it really
needs to do (in the audio engine) is allow connecting LADSPA plugin
"ports" to other plugins. LADSPA being what it is; that's not such a
difficult task (and most of the code could be borrowed from existing
projects anyway).
Agreed - at the lowest level it's a directed graph traversed in topological
order - a solved problem. The complicated bit is the interface and additional
functionality (subpatches etc), which is what differentiates existing synths. (If you think
this is just a stupid idea you should probably stop
reading now...)
Not at all. It's a great idea.
[...]
Anybody with more ideas/criteria for the
perfect modular synth?
OK here I go: From my notes (and fuzzy memory :), what I'd like is a simple cli
program that communicates via some form of IPC. OpenSoundControl (OSC) would
seem to be a good mechanism, as it's quite widely supported and should be
sufficient for all that would be required.
[chop] I agree with your points, besides the Audio + MIDI I/O
- I feel these would be
better implemented as non-plugins. There's also the sample load / save /
playback issue to consider.
I agree about the IO, it would probably be better to have those as
special things (but they'll still just appear as plugins with ports to
the user of course). See my note above about sampling, out of the
domain of this project.
For the
record, absolutely no disrespect towards authors of existing
efforts (ams, ssm, both great and certainly have their plusses), I
probably wouldn't have known what a modular synth was if it wasn't for
you guys ;). Gratitude..
Indeed. There's a lot of good ideas in all these apps - it's worth considering
whether efforts could be directed to improving these, rather than starting
totally from scratch. However, this is likely to be more difficult! (Also, yes,
I'm actually a coder, and yes, I'm willing to take this on
(time being limited as it may be).. I'm not one of those self-appointed
open-source-developer-dictators ;) )
I'm willing to help as well - I've been slacking off on this issue for too
long... -
Myk
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
15 Jan
15 Jan
2:48 p.m.
On Wed, 14 Jan 2004 13:04:09 -0500
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
It's when you have several connected plugins forming a single module
(I'll roll out my old example of an ADSR, a few DCOs, DCA etc) that GUI
generation really falls down. An alternative is that used in gAlan
(http://galan.sourceforge.net), where you build up your UI and hook it
up to whatever ports you like. Or PD - which lets you do ... just about
anything.
Making an "interface" or communication protocol, IPC, whatever you
wanna say I think is way way way overshooting what needs to be done.
What's the point really? The overhead is definately not worth it
(realtime audio..). The engine should be just code, straight up. We
need to design the architechture of the _program_ not an interface.
The engine would be straight up code. However, the interface would still
need to be defined as a set of functions for manipulating the engine.
All the OSC/IPC/whetever bit is for is to allow this manipulation to be
done by a program that is entirely separate from the engine. It is
likely that each OSC message (or whatever) would map one-for-one to each
function.
The overhead is minimal - it's not being used to stream audio, or
anything even close to that bandwidth.
I think the
main reason for this (for SSM at least) is firstly that
LADSPA support came after the app was developed, and secondly LADPSA
plugins don't have GUIs - these have to be generated, with limited
success. SSM is great in this regard - the native plugins all have
really cool GUIs.
Rather than having GUIs to control plugins, I was thinking ports would
be used for the most part.. real analog modulars don't have nifty GUIs
:). The GUI problem can be solved pretty well with a slightly more
advanced version of what SSM is doing (in CVS) right now... I havn't
really seen any LADSPA plugins that need more than a bunch of
sliders/knobs. The ideas ams/ssm have used are pretty good, but I
would add the
capability of choosing on an individual control basis whether the
control was in the GUI, or exported as a port. This is definately
something severely limiting about ams for me right now... (sure, you
can use MIDI out to get around it, but ew).
I agree - for most cases a separate sampler is fine. Composite
samples-plus-filters-and-stuff instruments might be trickier, but doable
(just send the Note On or whatever to both the sampler and the synth).
[...]
Another issue is that LADSPA plugins cannot be
used for sample
playback, as loading samples is impossible unless you stream the
data in a la SooperLooper(http://essej.net/sooperlooper).
This is where the simplicity comes in.. we're not making a sampler :).
Use an external sampler, if you want the audio in the synth, bring it
in as audio. Anybody with more ideas/criteria for the
perfect modular synth?
OK here I go: From my notes (and fuzzy memory :), what I'd like is a
simple cli program that communicates via some form of IPC.
OpenSoundControl (OSC) would seem to be a good mechanism, as it's
quite widely supported and should be sufficient for all that would
be required.[chop] If you really wanted a UI like what you described, it
could be
implemented as, well, a UI plugin. This is my idea anyway, if you
have some good rationale for a system like that please elaborate
What I was suggesting was not a *user* interface: I wouldn't expect the
user to control it directly by sending and receiving OSC messages!
For an excellent example of what I'm getting at, have a look at ecasound
(http://eca.cx) - a multitrack audio engine. This is controlled by the
Ecasound Control Interface (ECI) which can be used by any number of UIs,
both graphical and text based, to control a common engine (ecasound
itself) for a variety of purposes.
A full modular with a similar architecture to ecasound is what I'd like
to see.
, but I think
you're overthinking.
Guilty as charged. I do too much thinking, and not enough doing :)
I know, I'm really clinging to simplicity here,
but it's for good
reasons: simplicity breeds usefulness (UNIX), but more importantly,
simple means the damn thing will actually get _written_ :).
That's the idea - simplicity. I wouldn't want any (G)UI code anywhere
near the engine. The engine should know nothing of knobs, sliders or
whatever, just what it receives via its inputs.
I'm now motivated to get coding :)
-
Myk
5:53 p.m.
I think the way to make an inter app modular really useful and new would be
to use Jack for *ALL* signal passing including control signals as CV
emulations by passing a DC signal through Jack ( as say an equivalent of a
Csound krate signal or a hardware modular control volt signal.) If the
modular was some sort of framework for interconnecting apps and plugins
controlled by midi and Jack DC signals, one could actually accomplish the
kind of flexibility possible with hardware modulars and still be able to
incorporate other work.
Iain
----- Original Message -----
From: "Mike Rawes" <mike_rawes(a)yahoo.co.uk>
To: "The Linux Audio Developers' Mailing List"
<linux-audio-dev(a)music.columbia.edu>
Sent: Thursday, January 15, 2004 11:46 AM
Subject: Re: [linux-audio-dev] Project: modular synth editor
On Wed, 14 Jan 2004 13:04:09 -0500
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
It's when you have several connected plugins forming a single module
(I'll roll out my old example of an ADSR, a few DCOs, DCA etc) that GUI
generation really falls down. An alternative is that used in gAlan
(http://galan.sourceforge.net), where you build up your UI and hook it
up to whatever ports you like. Or PD - which lets you do ... just about
anything.
Making an "interface" or communication protocol, IPC, whatever you
wanna say I think is way way way overshooting what needs to be done.
What's the point really? The overhead is definately not worth it
(realtime audio..). The engine should be just code, straight up. We
need to design the architechture of the _program_ not an interface.
The engine would be straight up code. However, the interface would still
need to be defined as a set of functions for manipulating the engine.
All the OSC/IPC/whetever bit is for is to allow this manipulation to be
done by a program that is entirely separate from the engine. It is
likely that each OSC message (or whatever) would map one-for-one to each
function.
The overhead is minimal - it's not being used to stream audio, or
anything even close to that bandwidth.
I think
the main reason for this (for SSM at least) is firstly that
LADSPA support came after the app was developed, and secondly LADPSA
plugins don't have GUIs - these have to be generated, with limited
success. SSM is great in this regard - the native plugins all have
really cool GUIs.
Rather than having GUIs to control plugins, I was thinking ports would
be used for the most part.. real analog modulars don't have nifty GUIs
:). The GUI problem can be solved pretty well with a slightly more
advanced version of what SSM is doing (in CVS) right now... I havn't
really seen any LADSPA plugins that need more than a bunch of
sliders/knobs. The ideas ams/ssm have used are pretty good, but
I would add the
capability of choosing on an individual control basis whether the
control was in the GUI, or exported as a port. This is definately
something severely limiting about ams for me right now... (sure, you
can use MIDI out to get around it, but ew).
I agree - for most cases a separate sampler is fine. Composite
samples-plus-filters-and-stuff instruments might be trickier, but doable
(just send the Note On or whatever to both the sampler and the synth).
[...]
Another issue is that LADSPA plugins cannot be
used for sample
playback, as loading samples is impossible unless you stream the
data in a la SooperLooper(http://essej.net/sooperlooper).
This is where the simplicity comes in.. we're not making a sampler :).
Use an external sampler, if you want the audio in the synth, bring it
in as audio. Anybody with more ideas/criteria for the
perfect modular synth?
OK here I go: From my notes (and fuzzy memory :), what I'd like is a
simple cli program that communicates via some form of IPC.
OpenSoundControl (OSC) would seem to be a good mechanism, as it's
quite widely supported and should be sufficient for all that would
be required.[chop] If you really wanted a UI like what you
described, it could be
implemented as, well, a UI plugin. This is my idea anyway, if you
have some good rationale for a system like that please elaborate
What I was suggesting was not a *user* interface: I wouldn't expect the
user to control it directly by sending and receiving OSC messages!
For an excellent example of what I'm getting at, have a look at ecasound
(http://eca.cx) - a multitrack audio engine. This is controlled by the
Ecasound Control Interface (ECI) which can be used by any number of UIs,
both graphical and text based, to control a common engine (ecasound
itself) for a variety of purposes.
A full modular with a similar architecture to ecasound is what I'd like
to see.
, but I think
you're overthinking.
Guilty as charged. I do too much thinking, and not enough doing :)
I know, I'm really clinging to simplicity
here, but it's for good
reasons: simplicity breeds usefulness (UNIX), but more importantly,
simple means the damn thing will actually get _written_ :).
That's the idea - simplicity. I wouldn't want any (G)UI code anywhere
near the engine. The engine should know nothing of knobs, sliders or
whatever, just what it receives via its inputs.
I'm now motivated to get coding :)
-
Myk
16 Jan
16 Jan
2:14 a.m.
On Thu, 15 Jan 2004 14:53:18 -0800
"Iain Duncan" <iainduncan(a)telus.net> wrote:
I think the way to make an inter app modular really
useful and new
would be to use Jack for *ALL* signal passing including control
signals as CV emulations by passing a DC signal through Jack ( as say
an equivalent of a Csound krate signal or a hardware modular control
volt signal.) If the modular was some sort of framework for
interconnecting apps and plugins controlled by midi and Jack DC
signals, one could actually accomplish the kind of flexibility
possible with hardware modulars and still be able to incorporate other
work.
That would be possible, but using JACK between *every* plugin in the
graph would be overkill. JACK support is definitely a requirement
though.
-
Myk
3:21 a.m.
That would be possible, but using JACK between *every*
plugin in the
graph would be overkill. JACK support is definitely a requirement
though.
Well, it might be, but on the other hand making that possible would allow
the truely open ended flexibility possible with a hardware modular. If the
project is limited to midi control, the resolution of control signals is
forced into being very low. Being able to use use either a Jack/CV input or
a midi CC to control a paramater would be pretty cool. Plug ins wouldn't
have to be able to do everything, they could be used to do only one or two
things really well, and one could freely mix oscillators, filters, and other
processors to make complex patches.
Iain
4:19 a.m.
On Fri, Jan 16, 2004 at 12:21:42 -0800, Iain Duncan wrote:
There is a pretty signiciant overhead in passing control from one unit to
another in JACK, as compared to LADSPA-like APIs. Also the buffer size is
bound to the soundcards buffer size, which you dont generally want in a
modular system.
A modular system with internal modules that allows an arbitrary number of
JACK i/o modules is functionally equivalent, and much more efficient.
- Steve
That would be
possible, but using JACK between *every* plugin in the
graph would be overkill. JACK support is definitely a requirement
though.
Well, it might be, but on the other hand making that possible would allow
the truely open ended flexibility possible with a hardware modular. If the
4:31 a.m.
--- Iain Duncan <iainduncan(a)telus.net> wrote:
This is what AMS, SSM, gAlan, PD etc let you do right now - MIDI is converted
to a 'voltage' signal (by various means) and then routed to plugins in the
graph. Ditto JACK - you can connect a JACK port to anything you like in these
apps.
I don't think this kind of I/O is best implemented internally as a plugin
either (definitely not if plugin == LADSPA). It's better if it's provided by
the host as a bus or other metaphor.
-
Myk
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
That would be
possible, but using JACK between *every* plugin in the
graph would be overkill. JACK support is definitely a requirement
though.
Well, it might be, but on the other hand making that possible would allow
the truely open ended flexibility possible with a hardware modular. If the
project is limited to midi control, the resolution of control signals is
forced into being very low. Being able to use use either a Jack/CV input or
a midi CC to control a paramater would be pretty cool. Plug ins wouldn't
have to be able to do everything, they could be used to do only one or two
things really well, and one could freely mix oscillators, filters, and other
processors to make complex patches.
4:56 a.m.
This is what AMS, SSM, gAlan, PD etc let you do right
now - MIDI is
converted
to a 'voltage' signal (by various means) and
then routed to plugins in the
graph. Ditto JACK - you can connect a JACK port to anything you like in
these
apps.
I don't know near enough to say it should be Jack specifically that does the
inter-app passing of control signals. But my point is that *midi converted
to a signal* is insufficient. Midi is low depth low sample rate ( or baud in
this case ) totally impractical as say the input source on a filters CV in
case you wanted really tight envelopes. I'd like to see one module able to
generate a high res signal in some cool manner that can then be used for
whatever strikes my fancy, without worrying about the signal being too
coarse for my selected job. Or many modules each working one one signal that
in the very end goes into a filter cutoff plug. So say a user wants to
sequence something from midi, they could *start* the signal as 7 bit, but
once it's in the signal path it gets upped to 24 or 32 by audio sample rate
so that as it goes through envelopes, lfos, sample and holds, mixers, etc,
etc, we aren't processing a low quality signal. ( I hope I'm making some
kinda sense here. )
I guess what I'm really trying to say is just that we should keep an eye to
the future and make sure we enable the inter-app routing of HIGH resolution
control signals through some kind of easily accessible standard if we really
are trying to achieve a *modular*. The beauty of a modular is that you *can*
use an audio signal as a control signal and vice versa. It doesn't care, go
ahead, blow up your speakers! Sure, that does means higher overhead, but
personally, I'm a lot more interested in having my CPU choke on a killer
modular than being able to run yet another limited software synthesize, know
what I mean? Modulars are supposed to be expensive . . . ; )
Iain
6:55 a.m.
--- Iain Duncan <iainduncan(a)telus.net> wrote: >
Absolutely - you don't have to use MIDI, but thats how MIDI is typically dealt
with in existing modulars, so that existing hardware and sequencers can be used
to control them. Think of it as 'backwards compatibility'.
This is what
AMS, SSM, gAlan, PD etc let you do right now - MIDI is
converted
to a 'voltage' signal (by various means)
and then routed to plugins in the
graph. Ditto JACK - you can connect a JACK port to anything you like in
these
apps.
I don't know near enough to say it should be Jack specifically that does the
inter-app passing of control signals. But my point is that *midi converted
to a signal* is insufficient. Midi is low depth low sample rate ( or baud in
this case ) totally impractical as say the input source on a filters CV in
case you wanted really tight envelopes. I'd like to see one module able to
generate a high res signal in some cool manner that can then be used for
whatever strikes my fancy, without worrying about the signal being too
coarse for my selected job. Or many modules each working one one signal that
in the very end goes into a filter cutoff plug.
You can do this already in all the modulars discussed! It's the default
behaviour - they all use internal buffers (32 bit floats, giving 25bit
resolution) for routing between plugins - if you want to send any signal
between two or more apps, you can use JACK. It works!
So say a user wants to
sequence something from midi, they could *start* the signal as 7 bit, but
once it's in the signal path it gets upped to 24 or 32 by audio sample rate
so that as it goes through envelopes, lfos, sample and holds, mixers, etc,
etc, we aren't processing a low quality signal. ( I hope I'm making some
kinda sense here. )
Perfect sense. What I don't get is why you think this cannot be done with
existing software....
e.g.:
Rosegarden o-(MIDI)-> SSM ---(JACK)-o
| | |
| (JACK) |
| | \
o-(MIDI)-> gAlan -(JACK)---> AMS -(JACK)-> JackRack ...
| /
o-(MIDI)-> AMS ---(JACK)-o
... can be done!
-
Myk
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
8:26 a.m.
On Fri, Jan 16, 2004 at 01:56:21AM -0800, Iain Duncan wrote:
I guess what I'm really trying to say is just that
we should keep an eye to
the future and make sure we enable the inter-app routing of HIGH resolution
control signals through some kind of easily accessible standard if we really
are trying to achieve a *modular*. The beauty of a modular is that you *can*
this easily accessible standard (sh|c)ould be open sound control
(osc). it's widely supported, flexible, simple etc.
http://www.cnmat.berkeley.edu/OpenSoundControl/
cheers,
martin
2:59 a.m.
On Thu, Jan 15, 2004 at 02:53:18PM -0800, Iain Duncan wrote:
I think the way to make an inter app modular really
useful and new would be
to use Jack for *ALL* signal passing including control signals as CV
emulations by passing a DC signal through Jack ( as say an equivalent of a
Csound krate signal or a hardware modular control volt signal.) If the
modular was some sort of framework for interconnecting apps and plugins
controlled by midi and Jack DC signals, one could actually accomplish the
kind of flexibility possible with hardware modulars and still be able to
incorporate other work.
can be done in gAlan if you have the CPU Power.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
3:25 a.m.
On Thu, Jan 15, 2004 at 02:53:18PM -0800, Iain Duncan
wrote:
> I think the way to make an inter app modular really useful and new would
be
> to use Jack for *ALL* signal passing including
control signals as CV
> emulations by passing a DC signal through Jack ( as say an equivalent of
a
> Csound krate signal or a hardware modular control
volt signal.) If the
> modular was some sort of framework for interconnecting apps and plugins
> controlled by midi and Jack DC signals, one could actually accomplish
the
kind of
flexibility possible with hardware modulars and still be able to
incorporate other work.
can be done in gAlan if you have the CPU Power.
4:25 a.m.
On Thu, Jan 15, 2004 at 02:53:18PM -0800, Iain Duncan wrote:
I think the way to make an inter app modular really
useful and new would be
to use Jack for *ALL* signal passing including control signals as CV
emulations by passing a DC signal through Jack ( as say an equivalent of a
Csound krate signal or a hardware modular control volt signal.) If the
modular was some sort of framework for interconnecting apps and plugins
controlled by midi and Jack DC signals, one could actually accomplish the
kind of flexibility possible with hardware modulars and still be able to
incorporate other work.
It should be possible to do this with AMS 1.7.x, but I never tried.
There's a limit to the number of JACK ports (32 IIRC), but this is
compile time defined and can be increased.
But nothing is gained by doing all routing through JACK, and for
polyphonic patches this could become a nightmare (currently they are
mixed down at the JACK port).
In a similar way, AMS 1.7.x supports multichannel ALSA devices, and if
these are DC coupled you could use them to send / receive control voltages.
--
FA
3:37 p.m.
On Thu, 2004-01-15 at 17:53, Iain Duncan wrote:
I think the way to make an inter app modular really
useful and new would be
to use Jack for *ALL* signal passing including control signals as CV
emulations by passing a DC signal through Jack ( as say an equivalent of a
Csound krate signal or a hardware modular control volt signal.) If the
modular was some sort of framework for interconnecting apps and plugins
controlled by midi and Jack DC signals, one could actually accomplish the
kind of flexibility possible with hardware modulars and still be able to
incorporate other work.
Iain
An interesting idea for sure, but what's the point really? If you want
to export a certain bit of audio or control data to jack, just run it
into a jack output plugin.
Having every single connection, useful or not, done through jack would
make your jack patch bay SO incredibly complicated and crammed full of
garbage as to be totally useful.
But you're mashing the ideas of modules in an app and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
-Dave
3:59 p.m.
Having every single connection, useful or not, done
through jack would
make your jack patch bay SO incredibly complicated and crammed full of
garbage as to be totally useful.
But you're mashing the ideas of modules in an app and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
Speaking of complicated patchbays, one thing that might be worth bearing in
mind ( if it's not done already ) is allowing a *text* based patching
option. Has this been done already for other apps? For example, my csound
instruments are ridiculously complicated and would involve hundreds of
jacks, I would hate to try to program them with a gui. But with Vim and
Python helping me a long, patching in text is not so bad . . .
Just a thought!
Iain
4:10 p.m.
Dave Robillard wrote:
...
But you're mashing the ideas of modules in an app
and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
From a user's point of view, why should it be different problems? I
would want an application that presents both Jack clients and LADSPA
plugins as modules, and let me connect them however I want. There is no
reason I should have to instantiate "Jack IO modules" to access other
applications. Those ports should be created implicitly by the program
when I connect a LADSPA plugin and a Jack application.
I understand that for efficiency, it is probably not a good idea to
route all signals through jackd, but the choice of routing path should
be handled automatically by the application and not by the user.
Marcus
18 Jan
18 Jan
6:23 p.m.
On Fri, 2004-01-16 at 16:06, Marcus Andersson wrote:
Dave Robillard wrote:
...
Like I mentioned earlier, having jack used for every connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
Plugins in an app and connecting different apps is just different,
period. I can't think of any reason to pretend otherwise - it certainly
doesn't make things easier from a user perspective.
If you want a jack audio out somewhere in your synth.... put one there.
You can't possibly be arguing that this is too difficult?
-Dave
But you're mashing the ideas of modules in an
app and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
From a user's point of view, why should it be different problems? I
would want an application that presents both Jack clients and LADSPA
plugins as modules, and let me connect them however I want. There is no
reason I should have to instantiate "Jack IO modules" to access other
applications. Those ports should be created implicitly by the program
when I connect a LADSPA plugin and a Jack application.
I understand that for efficiency, it is probably not a good idea to
route all signals through jackd, but the choice of routing path should
be handled automatically by the application and not by the user.
7:02 p.m.
Like I mentioned earlier, having jack used for every
connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
Plugins in an app and connecting different apps is just different,
period. I can't think of any reason to pretend otherwise - it certainly
doesn't make things easier from a user perspective.
From a programming perspective I'm sure you're
right. But the truth is that
a modular is *exactly* like having Jack do every
connection, that's what a
modular synth is! They aren't easy to patch or easy to use!
Iain
7:07 p.m.
On Sun, 2004-01-18 at 19:02, Iain Duncan wrote:
You seem to be really attached to this idea.. I guess what I don't
understand is.. why? What, exactly, is the point/benefit?
- It adds /no/ flexibility
(Doesn't make anything possibly that isn't already)
- It adds a /lot/ of complexity
(Your jack patch bay will basically become useless)
Examples to the contrary are welcome, but I really just don't understand
why you want this.
-Dave
Like I
mentioned earlier, having jack used for every connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
Plugins in an app and connecting different apps is just different,
period. I can't think of any reason to pretend otherwise - it certainly
doesn't make things easier from a user perspective.
From a programming perspective I'm sure
you're right. But the truth is that
a modular is *exactly* like having Jack do
every connection, that's what a
modular synth is! They aren't easy to patch or easy to use!
Iain
7:30 p.m.
You seem to be really attached to this idea.. I guess
what I don't
understand is.. why? What, exactly, is the point/benefit?
It's really not that I think anyone should follow my suggestions, I'm not an
experienced enough programmer. The reason I piped up again was because I
think it is very easy for computer programmers emulating a modular to lose
track of what a modular actually is/does. So if that is the stated goal,
keeping an eye on the definition is important. I also tend to think that
historically programmers often say:
"Oh that will be way too impractical to use and CPU intensive" and two years
down the road it's a different story. Csound is a perfect example, it's
flexible as a real time instrument now because the design was never intended
for real time use. No one was worried about how CPU hungry it is.
So all I'm saying is keep in mind these points about a hardware modular if
you really want to make a software one:
One standard type of connection ( a jack ) can be used between modules of
different manufacturers for all of:
- instantaneous audio feedback ( well speed of light anyway! )
- any audio signal can be used as a control signal and vice versa
- any signal can be used to cross modulate or mix with any other signal
- a signal can be used for as long as wanted in a control chain without
worrying about resolution loss ( sure it may get distorted, but the
distortion is also happening at the speed of light. )
For example, the ear is *extremely* sensitive to the coarseness of an
amplitude enveloping signal. ( You can hear the difference between a 44khz
and a 10khz envelope signal applied to amplitude. ) Anything less than audio
resolution is noticeable. So if you want *any* signal source to be able to
go *anywhere* then that signal has to be audio resolution all the time. If
this is the case, why not use the best standard we have for passing signals?
That will be expensive, and that will be a modular. Anything less is IMHO
not a *modular* though it might well still be a wicked modularish-app.
However, this does not mean that I don't think other approaches will make
wicked audio software. We are always stuck choosing between expense and
features, and many choices are valid. In my live Csound rig I cut corners
for fast response all the time. But it ain't no modular . . .
Iain
7:43 p.m.
On Sun, 2004-01-18 at 19:30, Iain Duncan wrote:
That's great. You've totally missed my point though. Yep, modulars are
general. The great thing about them is you can do anything, and connect
anything in any way you want.
Alsa and Jack are great (right now). The great thing about them is you
can do anything, and connect anything in any way you want.
What you're asking for _has no benefit_! Only downsides.
By all means, if you can come up with some reason why it would be cool
or useful, I'll admit defeat, but (no offense) ramblings about what a
modular synth is don't really mean anything :)
-Dave
You seem to be
really attached to this idea.. I guess what I don't
understand is.. why? What, exactly, is the point/benefit?
It's really not that I think anyone should follow my suggestions, I'm not an
experienced enough programmer. The reason I piped up again was because I
think it is very easy for computer programmers emulating a modular to lose
track of what a modular actually is/does. So if that is the stated goal,
keeping an eye on the definition is important.
So all I'm saying is keep in mind these points about a hardware modular if
you really want to make a software one:
One standard type of connection ( a jack ) can be used between modules of
different manufacturers for all of:
- instantaneous audio feedback ( well speed of light anyway! )
- any audio signal can be used as a control signal and vice versa
- any signal can be used to cross modulate or mix with any other signal
- a signal can be used for as long as wanted in a control chain without
worrying about resolution loss ( sure it may get distorted, but the
distortion is also happening at the speed of light. )
8:52 p.m.
New subject: [linux-audio-dev] Best threads for real time on 2.6?
Hoping some one can throw some light on this for me, I've been dutifully
doing my best to research it but am overwhelmed with all the info, much of
which looks like it might be out of date.
The object is to port my csound sequencer to C and run it on linux. It will
be a real time multi threaded sequencer that embeds csound as the audio
engine and passes events to the embedded csound. The sequencer is controlled
by midi input, and midi output happens through Csound. ( to allow users to
easily hack at the midi output without having to learn C ) I aim to have the
thread holding csound and the thread holding the engine have as high
priority as possible, while the threads for user input, data transformation
and manipulation, and any optional GUI will be lower priority and will wait
patiently or do their tasks slowly so as not to interfere with playback. I'm
confused as to which approach to threading I should be researching the most.
As this won't be done any time soon, I expect to working with the 2.6
kernel. Any feedback on kernel threads vs user threads, especially regarding
Posix threads ( and specific implentations of them ) would be appreciated.
If it's possible to even do disk i/o without interferring with the playback
and audio that would be even better. Pointers to good up-to-date resources
would be great too. I know Paul did this with Softwerk, but as that was
written a while ago I want to make sure I don't spend too much time looking
at solutions that perhaps have been improved upon with recent linux
threading advances.
Thanks so much
Iain
19 Jan
19 Jan
4:28 a.m.
New subject: [linux-audio-dev] Best threads for real time on 2.6?
On Sun, Jan 18, 2004 at 05:52:17PM -0800, Iain Duncan wrote:
Hoping some one can throw some light on this for me,
I've been dutifully
doing my best to research it but am overwhelmed with all the info, much of
which looks like it might be out of date.
You just need JACK. http://jackit.sf.net
JACK automatically makes your audio thread realtime and there are ways to
make it give your other RT threads realtime priorities if you need to.
POSIX threads are the ones people use for audio work.
Disk i/o is no problem, as long as the thread thats doing the disk i/o is
not RT. There are plenty of examples of this, eg in the JACK example
clients directory.
- Steve
18 Jan
18 Jan
9:03 p.m.
On Sun, Jan 18, 2004 at 07:40:43PM -0500, Dave Robillard wrote:
On Sun, 2004-01-18 at 19:30, Iain Duncan wrote:
The point is IMHO that JACK is great for making audio connections between
independent Linux processes - that what it's designed for, and what it does
extremely well (BTW congrats to Paul and the whole JACK team for the Open
Source Award). But using JACK for internal connections is pure overkill,
and I'm not even sure it will work as you expect.
--
FA
One standard type of connection ( a jack ) can be
used between modules of
different manufacturers for all of:
- instantaneous audio feedback ( well speed of light anyway! )
- any audio signal can be used as a control signal and vice versa
- any signal can be used to cross modulate or mix with any other signal
- a signal can be used for as long as wanted in a control chain without
worrying about resolution loss ( sure it may get distorted, but the
distortion is also happening at the speed of light. )
That's great. You've totally missed my point though. Yep, modulars are
general. The great thing about them is you can do anything, and connect
anything in any way you want.
9:37 p.m.
On Sun, 2004-01-18 at 20:56, Fons Adriaensen wrote:
On Sun, Jan 18, 2004 at 07:40:43PM -0500, Dave
Robillard wrote:
.. yep, that's my point. Well put. :)
-Dave
On Sun, 2004-01-18 at 19:30, Iain Duncan wrote:
The point is IMHO that JACK is great for making audio connections between
independent Linux processes - that what it's designed for, and what it does
extremely well (BTW congrats to Paul and the whole JACK team for the Open
Source Award). But using JACK for internal connections is pure overkill,
and I'm not even sure it will work as you expect. One standard type of connection ( a jack ) can be
used between modules of
different manufacturers for all of:
- instantaneous audio feedback ( well speed of light anyway! )
- any audio signal can be used as a control signal and vice versa
- any signal can be used to cross modulate or mix with any other signal
- a signal can be used for as long as wanted in a control chain without
worrying about resolution loss ( sure it may get distorted, but the
distortion is also happening at the speed of light. )
That's great. You've totally missed my point though. Yep, modulars are
general. The great thing about them is you can do anything, and connect
anything in any way you want.
19 Jan
19 Jan
10:35 a.m.
On Mon, Jan 19, 2004 at 02:56:52AM +0100, Fons Adriaensen wrote:
The point is IMHO that JACK is great for making audio
connections between
independent Linux processes - that what it's designed for, and what it does
extremely well (BTW congrats to Paul and the whole JACK team for the Open
Source Award). But using JACK for internal connections is pure overkill,
and I'm not even sure it will work as you expect.
Sorry to follow upp on my own ramblings, but I'm getting more and more
convinced that using JACK for internal connections in a modular synth will
not work as expected.
For example, take the patch
JACK -> A -> JACK -> B -> JACK
where A and B are two processing modules.
If A and B are inside the same JACK client, what will happen ?
Will jack use a single buffer for A-out and B-in (this is what you'd
expect in a modular synth), or will it copy the previous A-out to B-in
before calling your process callback, thereby introducing one cycle
delay ?
--
FA
12:11 p.m.
On Mon, Jan 19, 2004 at 04:09:14PM +0100, Fons Adriaensen wrote:
JACK -> A -> JACK -> B -> JACK
where A and B are two processing modules.
If A and B are inside the same JACK client, what will happen ?
Will jack use a single buffer for A-out and B-in (this is what you'd
expect in a modular synth), or will it copy the previous A-out to B-in
before calling your process callback, thereby introducing one cycle
delay ?
It will use the same buffer, but I still dont think its a good idea :)
- Steve
2:55 p.m.
Fons Adriaensen wrote:
On Mon, Jan 19, 2004 at 02:56:52AM +0100, Fons
Adriaensen wrote:
If A and B are modules *inside the same JACK client* (rather than, for
instance, two JACK clients instantiated by the same application) then
the situation is something like this:
+---------------+
| +-------+ |
JACK ------>|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
Note that the client contains connectivity that is invisible to JACK: As
far as
JACK can tell the client is a black box with 2 inputs and 2 outputs,
requiring
a single process callback (which is all that a client is going to get in
any case).
Will a delay be introduced? Not so long as the client processes A before B
in its callback. But *neither JACK nor the client* posesses the information
to determine that this is the correct order!
Worse:
JACK -> A -> JACK -> C -> JACK -> B -> JACK
Where C is in a separate client.
Now...
+-------+
| |
+---|<- C <-|<--+
| | | |
| +-------+ |
| |
| +-------+ |
JACK ------>|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
Oh dear... C needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
Simon Jenkins
(Bristol, UK)
The point is IMHO that JACK is great for making
audio connections between
independent Linux processes - that what it's designed for, and what it does
extremely well (BTW congrats to Paul and the whole JACK team for the Open
Source Award). But using JACK for internal connections is pure overkill,
and I'm not even sure it will work as you expect.
Sorry to follow upp on my own ramblings, but I'm getting more and more
convinced that using JACK for internal connections in a modular synth will
not work as expected.
For example, take the patch
JACK -> A -> JACK -> B -> JACK
where A and B are two processing modules.
If A and B are inside the same JACK client, what will happen ?
Will jack use a single buffer for A-out and B-in (this is what you'd
expect in a modular synth), or will it copy the previous A-out to B-in
before calling your process callback, thereby introducing one cycle
delay ?
4:30 p.m.
Whoops: Those ascii diagrams again:
+---------------+
| +-------+ |
JACK ----->|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
+-------+
| |
+---|<- C <-|<--+
| | | |
| +-------+ |
| |
| +-------+ |
JACK ----->|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
(also available as an attachment)
+---------------+
| +-------+ |
JACK ----->|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
+-------+
| |
+---|<- C <-|<--+
| | | |
| +-------+ |
| |
| +-------+ |
JACK ----->|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
6:19 p.m.
On Mon, Jan 19, 2004 at 08:56:52PM +0000, Simon Jenkins wrote:
Worse:
JACK -> A -> JACK -> C -> JACK -> B -> JACK
Where C is in a separate client.
Now...
+-------+
| |
+---|<- C <-|<--+
| | | |
| +-------+ |
| |
| +-------+ |
JACK ------>|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
Oh dear... C needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
This will 'work', AFAICS, but with one cycle delay. This sets me thinking
about using JACK for insertion points in a mixer. This will always introduce
extra delays...
--
FA
7:07 p.m.
On Mon, Jan 19, 2004 at 11:41:30 +0100, Fons Adriaensen wrote:
Yes, unless the front half and back half of the mixer are seperate jack
clients, but I dont think thats a good idea :)
The same will be true in any modular system where the process() methods
are atomic.
- Steve
Oh dear... C
needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
This will 'work', AFAICS, but with one cycle delay. This sets me thinking
about using JACK for insertion points in a mixer. This will always introduce
extra delays...
7:59 p.m.
Steve Harris wrote:
On Mon, Jan 19, 2004 at 11:41:30 +0100, Fons Adriaensen
wrote:
Yes, unless the front half and back half of the mixer are seperate jack
clients, but I dont think thats a good idea :)
Even making the front half and back half of the mixer into separate
clients can be
defeated by a sufficiently pathological user. (Eg by chaining all the
input sections
together in the "wrong" order).
Simon Jenkins
(Bristol, UK)
Oh dear...
C needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
This will 'work', AFAICS, but with one cycle delay. This sets me thinking
about using JACK for insertion points in a mixer. This will always introduce
extra delays...
7:54 p.m.
Fons Adriaensen wrote:
On Mon, Jan 19, 2004 at 08:56:52PM +0000, Simon Jenkins
wrote:
One or two cycles, depending on whether the client containing A and B
guesses
correctly that A comes before B in the overall graph. (It doesn't know).
Worse:
JACK -> A -> JACK -> C -> JACK -> B -> JACK
Where C is in a separate client.
Now...
+-------+
| |
+---|<- C <-|<--+
| | | |
| +-------+ |
| |
| +-------+ |
JACK ------>|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
Oh dear... C needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
This will 'work', AFAICS, but with one cycle delay.
This sets me thinking
about using JACK for insertion points in a mixer. This will always introduce
extra delays...
Once you start routing data out of a client and back into it, neither
JACK nor the
client know how to order their graphs. A mixer client could guess that
the pre-insert
sections of its signal paths precede the post-insert sections
(minimizing, but not
eliminating, the extra delays) but even this could be wrong: The user
might have
used JACK to "insert" one path through the mixer into another path
through the
mixer.
In the case of interconnecting modular synths via JACK it gets even worse
because the internal graphs of the synths will be changeable. In the
extreme this
could cause glitches if an adjustment to the routing within a synth app
caused
the number of introduced delay cycles to change.
Simon Jenkins
(Bristol, UK)
20 Jan
20 Jan
6 a.m.
On Tue, Jan 20, 2004 at 01:55:54 +0000, Simon Jenkins wrote:
No, its always 1, theres no "guessing" what the order is, the graph is
sorted by the jack demon.
Feedback loops are the only time you get arbitrary extra latencies, jack
has to choose to break the loop somewhere, generally it doesnt really
matter where.
This will
'work', AFAICS, but with one cycle delay.
One or two cycles, depending on whether the client containing A and B
guesses
correctly that A comes before B in the overall graph. (It doesn't know). This sets me
thinking
about using JACK for insertion points in a mixer. This will always
introduce
extra delays...
Once you start routing data out of a client and back into it, neither
JACK nor the
client know how to order their graphs. A mixer client could guess that
the pre-insert
sections of its signal paths precede the post-insert sections
(minimizing, but not
eliminating, the extra delays) but even this could be wrong: The user
might have
used JACK to "insert" one path through the mixer into another path
through the
mixer. In the case of interconnecting modular synths via JACK
it gets even worse
because the internal graphs of the synths will be changeable. In the
extreme this
could cause glitches if an adjustment to the routing within a synth app
caused
the number of introduced delay cycles to change.
In the general case you will get glitches on graph connections anyway -
jack has to erform some non-RT operations.
- Steve
3:42 p.m.
Steve Harris wrote:
On Tue, Jan 20, 2004 at 01:55:54 +0000, Simon Jenkins
wrote:
No, its always 1,
Actually, yes it is always 1 ( the totally incorrect BCA is unachievable
for the same reason that the totally correct ACB is: Because C can never
execute in between A and B). My mistake, but I'm still describing a real
problem:
This will
'work', AFAICS, but with one cycle delay.
One or two cycles, depending on whether the client containing A and B
guesses
correctly that A comes before B in the overall graph. (It doesn't know).
theres no "guessing" what the order is, the
graph is
sorted by the jack demon.
There *is* guessing.
The trouble comes when clients have non-trivial internal graphs of
their own. JACK can't see the internal graphs of clients. It assumes
that all outputs of a client are dependent on all inputs of that client,
so any attempt to route a signal out of a client and then back into it
looks like feedback to JACK, even when there isn't any real feedback
going on.
And the client can't see the external JACK graph either. If a client's
internal graph consists of two disjoint subgraphs...
: ########################
: # #
: >in1 --> MOD A --> out1>
: # #
: >in2 --> MOD B --> out2>
: # #
: ########################
...then the client doesn't know which subgraph to process first. If the
user has connected out1 directly to in2 then it should do the MOD A
chain first, but if the user has connected out2 directly to in1 then it
should do the MOD B chain first. If the client guesses wrong then
an unnecessary delay is introduced.
If the user has connected out2 *indirectly* back to in1 then the MOD B
chain should execute first, followed by some other stuff in some other
clients, followed by the MOD A chain. But even if JACK and the client
cooperated to find this out (neither could work it out for themselves) it
would require per-input process callbacks from JACK - rather than
per-client callbacks - to achieve it.
I actually started coding a mod to JACK last year to deal with this
stuff, but then got suck(er)ed down a sidetrack from which I haven't
so far returned.
Simon Jenkins
(Bristol, UK)
19 Jan
19 Jan
4:21 a.m.
On Sun, Jan 18, 2004 at 04:02:43PM -0800, Iain Duncan wrote:
Think of jack as being the wires you run between racks.
I disagree FWIW, I think modular synths are very easy to use, or should
be. Hardware modulars are easy to use (well, untill you have to start
spagetti diving), and s/w one can be if enough thought is put into the UI.
- Steve
From a
programming perspective I'm sure you're right. But the truth is that
a
modular is *exactly* like having Jack do every connection, that's what a
modular synth is! They aren't easy to patch or easy to use!
1:43 p.m.
Dave Robillard wrote:
On Fri, 2004-01-16 at 16:06, Marcus Andersson wrote:
Maybe I didn't express myself clear enough earlier, but I agree
completely with what you say above. Internal signal routing should be
handled by the application. External signal routing should use Jack.
Dave Robillard wrote:
...
Like I mentioned earlier, having jack used for every connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
But you're mashing the ideas of modules in an
app and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
From a user's point of view, why should it be different problems? I
would want an application that presents both Jack clients and LADSPA
plugins as modules, and let me connect them however I want. There is no
reason I should have to instantiate "Jack IO modules" to access other
applications. Those ports should be created implicitly by the program
when I connect a LADSPA plugin and a Jack application.
I understand that for efficiency, it is probably not a good idea to
route all signals through jackd, but the choice of routing path should
be handled automatically by the application and not by the user.
Plugins in an app and connecting different apps is just
different,
period. I can't think of any reason to pretend otherwise - it certainly
doesn't make things easier from a user perspective.
If you want a jack audio out somewhere in your synth.... put one there.
You can't possibly be arguing that this is too difficult?
Of course it isn't difficult, but if the creation of "jack audio out"
ports can be handled automatically by the application behind the scene,
it will simplify the user interaction. But this is not the only benefit.
The user will also be able see the complete audio routing graph in one
place, and don't need to switch between applications to do so.
I understand that you want to write a traditional modular synthesizer
and that you don't consider a Jack application to be just another
module. But it could be, and the synth could still be as efficient.
I am looking forward to use your synthesizer, whatever it will look
like. Good luck.
Marcus
1:59 p.m.
On Mon, 2004-01-19 at 13:39, Marcus Andersson wrote:
Dave Robillard wrote:
Users can handle adding an oscillator and connecting it, what's so
different about an output? If the app does it "behing the scene"..
well, what does the user plug their "cable" into??
I think maybe you're talking about a combination analog modular and jack
patch bay? That does sound like a pretty cool idea at the start, until
you realize the things you want to route your audio through are
_seperate applications_, they're going to appear as such no matter what
you do. I really think the problem of a better jack patch bay and
writing some synth are very different problems, smashing them together
just doesn't make sense to me.
On Fri, 2004-01-16 at 16:06, Marcus Andersson
wrote:
Maybe I didn't express myself clear enough earlier, but I agree
completely with what you say above. Internal signal routing should be
handled by the application. External signal routing should use Jack.
Dave Robillard wrote:
...
Like I mentioned earlier, having jack used for every connection in, say,
a modular synth, would make your jack patching too complicated to be
useful. This most definatley would not be easier to use.
But you're mashing the ideas of modules in an
app and connecting
multiple apps together - different problems. A jack patch bay that
works like a modular would definately be cool, but a totally different
project.
From a user's point of view, why should it be different problems? I
would want an application that presents both Jack clients and LADSPA
plugins as modules, and let me connect them however I want. There is no
reason I should have to instantiate "Jack IO modules" to access other
applications. Those ports should be created implicitly by the program
when I connect a LADSPA plugin and a Jack application.
I understand that for efficiency, it is probably not a good idea to
route all signals through jackd, but the choice of routing path should
be handled automatically by the application and not by the user.
Plugins in an app and connecting different apps is
just different,
period. I can't think of any reason to pretend otherwise - it certainly
doesn't make things easier from a user perspective.
If you want a jack audio out somewhere in your synth.... put one there.
You can't possibly be arguing that this is too difficult?
Of course it isn't difficult, but if the creation of "jack audio out"
ports can be handled automatically by the application behind the scene,
it will simplify the user interaction. But this is not the only benefit.
The user will also be able see the complete audio routing graph in one
place, and don't need to switch between applications to do so. I understand that you want to write a traditional
modular synthesizer
and that you don't consider a Jack application to be just another
module. But it could be, and the synth could still be as efficient.
"Jack application as just another module".. now I think I see what
you're saying. I suppose it would be possible, but every application
you use would definately have to be LADCCA-fied. Otherwise this prog is
going to have to handle launching every single app you plan to use
(ugh).
I am looking forward to use your synthesizer, whatever
it will look
like. Good luck.
Thanks, though I might actually start tackling the patch bay problem
first, as it's simpler and the UI stuff will carry over to the synth
anyway (plus I really want a modular-ish jack patch bay ;) ). Who
knows, maybe it will evolve in such a way that they are combined like
you're thinking, but I think that idea needs some _serious_ thought
beforehand.
Being a full-time computer science student doesn't exactly leave all
that much free time to hack, but I'll see...
-Dave
16 Jan
16 Jan
3:34 p.m.
On Thu, 2004-01-15 at 14:46, Mike Rawes wrote:
Exactly. That's not that much trickier - hell, I do it all the time
right now :) (alsa seq is awesome..)
It's when you have several connected plugins
forming a single module
(I'll roll out my old example of an ADSR, a few DCOs, DCA etc) that GUI
generation really falls down. An alternative is that used in gAlan
(http://galan.sourceforge.net), where you build up your UI and hook it
up to whatever ports you like. Or PD - which lets you do ... just about
anything.
I suppose you have a point, nice UIs for a subpatch would be a nice
thing. Not a very complicated thing to implement in a host though,
especially in something like AMS which already has the ability to
control pretty much any parameter (right now from MIDI). Literally
defining in the subpatch "these things should be on the master subpatch
GUI" (just a big list of params) and letting the app draw them as it
pleases, as with current normal LADSPA plugins.
Subpatch GUIs are a good idea I didn't think of, and doing something
like the above (assuming I was making any sense at all) doesn't seem
very difficult or like it would have any major problems that I can see.
Comments?
The ideas
ams/ssm have used are pretty good, but I would add the
capability of choosing on an individual control basis whether the
control was in the GUI, or exported as a port. This is definately
something severely limiting about ams for me right now... (sure, you
can use MIDI out to get around it, but ew).
I agree - for most cases a separate sampler is fine. Composite
samples-plus-filters-and-stuff instruments might be trickier, but doable
(just send the Note On or whatever to both the sampler and the synth). Another issue is that LADSPA plugins cannot be
used for sample
playback, as loading samples is impossible unless you stream the
data in a la SooperLooper(http://essej.net/sooperlooper).
This is where the simplicity comes in.. we're not making a sampler :).
Use an external sampler, if you want the audio in the synth, bring it
in as audio. [...]
Making an "interface" or communication protocol, IPC, whatever you
wanna say I think is way way way overshooting what needs to be done.
What's the point really? The overhead is definately not worth it
(realtime audio..). The engine should be just code, straight up. We
need to design the architechture of the _program_ not an interface.
The engine would be straight up code. However, the interface would still
need to be defined as a set of functions for manipulating the engine.
All the OSC/IPC/whetever bit is for is to allow this manipulation to be
done by a program that is entirely separate from the engine. It is
likely that each OSC message (or whatever) would map one-for-one to each
function.
The overhead is minimal - it's not being used to stream audio, or
anything even close to that bandwidth.
But.. why? Any "interface" (other than just functions/classes that are
Just There) is a LOT of added complexity. More importantly perhaps is
overhead, 'cause there's going to be quite a bit.
The million dollar question: why?
Frontends can be built as a part of the project (like alsa patch bay for
example, fltk and gtkmm). I completely fail to see the point of sending
"messages" around, just to have a UI.
Anybody with more ideas/criteria for the
perfect modular synth?
OK here I go: From my notes (and fuzzy memory :), what I'd like is a
simple cli program that communicates via some form of IPC.
OpenSoundControl (OSC) would seem to be a good mechanism, as it's
quite widely supported and should be sufficient for all that would
be required.[chop] If you really wanted a UI like what you
described, it could be
implemented as, well, a UI plugin. This is my idea anyway, if you
have some good rationale for a system like that please elaborate
What I was suggesting was not a *user* interface: I wouldn't expect the
user to control it directly by sending and receiving OSC messages!
For an excellent example of what I'm getting at, have a look at ecasound
(http://eca.cx) - a multitrack audio engine. This is controlled by the
Ecasound Control Interface (ECI) which can be used by any number of UIs,
both graphical and text based, to control a common engine (ecasound
itself) for a variety of purposes. That's the idea - simplicity. I wouldn't want
any (G)UI code anywhere
near the engine. The engine should know nothing of knobs, sliders or
whatever, just what it receives via its inputs.
The GUI code need not be anywhere remotely close to the engine code,
it's not necessary to have some message-passing interface to accomplish
this.
17 Jan
17 Jan
5:28 a.m.
On Fri, Jan 16, 2004 at 03:32:17 -0500, Dave Robillard wrote:
On Thu, 2004-01-15 at 14:46, Mike Rawes wrote:
There more to it than that, take a look at the nord modular UI (it has the
best modular synth UI IMNSHO):
http://www.clavia.com/pictures/nordmodular/patchwindowlarge.jpg
I dont think you are going to get that quality of module layout and space
efficiency and ease of use with automatic GUIs.
It's when you have several connected plugins
forming a single module
(I'll roll out my old example of an ADSR, a few DCOs, DCA etc) that GUI
generation really falls down. An alternative is that used in gAlan
(http://galan.sourceforge.net), where you build up your UI and hook it
up to whatever ports you like. Or PD - which lets you do ... just about
anything.
I suppose you have a point, nice UIs for a subpatch would be a nice
thing. Not a very complicated thing to implement in a host though,
especially in something like AMS which already has the ability to
control pretty much any parameter (right now from MIDI). Literally
defining in the subpatch "these things should be on the master subpatch
GUI" (just a big list of params) and letting the app draw them as it
pleases, as with current normal LADSPA plugins. 
The GUI code need not be anywhere remotely close to
the engine code,
it's not necessary to have some message-passing interface to accomplish
this.
I keep coming back to this, but I dont think I've made the point well
enough - the external UI control data has to be routed to the host -
the host needs to keep a (sample accurate) log of all the control data
that is sent to the plugin so that it can have reproducability.
If you use OSC-like systems that doesnt require that the data flow through
the host, but its much easier if it does.
- Steve
18 Jan
18 Jan
6:39 p.m.
On Sat, 2004-01-17 at 05:25, Steve Harris wrote:
Well, yes, they do need to communicate of course, I was just saying
there's no point of a message-passing interface or whatever, the code
can still be modular w/o such a system.
On Fri, Jan 16, 2004 at 03:32:17 -0500, Dave Robillard
wrote:
Alright, having plugin GUIs _would_ be really cool, but I (personally)
just don't feel like wasting my time talking about it because I really
don't see anything along those lines happening soon.
On Thu, 2004-01-15 at 14:46, Mike Rawes wrote:
There more to it than that, take a look at the nord modular UI (it has the
best modular synth UI IMNSHO):
http://www.clavia.com/pictures/nordmodular/patchwindowlarge.jpg
I dont think you are going to get that quality of module layout and space
efficiency and ease of use with automatic GUIs. It's when you have several connected plugins
forming a single module
(I'll roll out my old example of an ADSR, a few DCOs, DCA etc) that GUI
generation really falls down. An alternative is that used in gAlan
(http://galan.sourceforge.net), where you build up your UI and hook it
up to whatever ports you like. Or PD - which lets you do ... just about
anything.
I suppose you have a point, nice UIs for a subpatch would be a nice
thing. Not a very complicated thing to implement in a host though,
especially in something like AMS which already has the ability to
control pretty much any parameter (right now from MIDI). Literally
defining in the subpatch "these things should be on the master subpatch
GUI" (just a big list of params) and letting the app draw them as it
pleases, as with current normal LADSPA plugins. The GUI code
need not be anywhere remotely close to the engine code,
it's not necessary to have some message-passing interface to accomplish
this.
I keep coming back to this, but I dont think I've made the point well
enough - the external UI control data has to be routed to the host -
the host needs to keep a (sample accurate) log of all the control data
that is sent to the plugin so that it can have reproducability.
16 Jan
16 Jan
1:58 p.m.
On Wed, 2004-01-14 at 15:14, Mike Rawes wrote:
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
I think there's a bit of misunderstanding here; LADCCA is nothing to do
with LADSPA; it's actually more for the former; audio and midi
connection state save and restore.
Bob
--
Bob Ham <rah(a)bash.sh>
"Discussion without action is just a pressure wave in air."
-- Daniel James
17 Jan
17 Jan
8:03 a.m.
On Fri, 16 Jan 2004 18:54:01 +0000
Bob Ham <rah(a)bash.sh> wrote:
On Wed, 2004-01-14 at 15:14, Mike Rawes wrote:
Oops. I meant LCP (http://www.equalarea.com/paul/lcp.html)
LADCCA support would be good as well, though...
-
Myk
* Managing inputs/outputs
JACK for audio (be it actual audio, or control
values at audio rate)
OSC 'ports' for control-rate connections
MIDI connections
OSS / ALSA audio I/O ?
LADCCA, iirc, is designed for controlling
LADSPA plugins remotely - worth checking out anyway
http://pkl.net/~node/ladcca.html
I think there's a bit of misunderstanding here; LADCCA is nothing to
do with LADSPA; it's actually more for the former; audio and midi
connection state save and restore.
7405
days inactive
7414
days old
linux-audio-dev@lists.linuxaudio.org
120 comments
24 participants
participants (24)
-
Alfons Adriaensen -
Bob Ham -
Brad Arant -
Dave Griffiths -
Dave Robillard -
Fons Adriaensen -
Frank Barknecht -
Iain Duncan -
Jens M Andreasen -
Jesper Anderson -
Joost Diepenmaat -
Juhana Sadeharju -
Luke Yelavich -
Marcus Andersson -
martin rumori -
Matthias Nagorni -
Mike Rawes -
Nathaniel Virgo -
RTaylor -
Simon Jenkins -
Steve Harris -
Thomas Webb -
Tim Goetze -
torbenhï¼ gmx.de