5 Feb
2004
5 Feb
'04
3:14 a.m.
On Thu, 2004-02-05 at 01:07, Juhana Sadeharju wrote:
This is what LADCCA is for really.. session management is well out of
the domain of a patch bay, IMO
I do plan on having the ability to save module positions (with LADCCA
sessions), and of course manual placement is there. But it would still
be nice to have a nice algorithm for automatic placement. Just being
able to start all your programs paying no attention to your patch bay,
but having it nicely organized when you get to it would be nice.
If course, as someone already said (Steve?) if you loaded up all the
apps you use frequently, positioned them well and saved that, it would
be what you want most of the time (people tend to use the apps they use,
heh). Of course, only apps that are running would show up.
From: Dave
Robillard <drobilla(a)connect.carleton.ca>
Screenshot:
http://chat.carleton.ca/~drobilla/patchbay.png
[ ... ]
Eventually it will be a combined jack/alsa patch
bay
How about adding an application menu from which user may
launch new applications and insert to the patchbay?
Patchbay would store application's command line parameters.
How about a custom application menu where user has edited the default
command line parameters? E.g., a Fluidsynth would start with a sample
file: "fluidsynth-808perc". Of course, applications should support
configuration and sample loading via command line. How Alsa mixer relates to Patchbay? If I record
Alsa's line-in,
the reverberated output should not be mixed to the recording.
And other way, if I record reverberation, the original should not
be recorded. Could there be a Alsa module which has more connections
than capture1,2 and playback1,2? When I launch Alsamixer, I would
control levels with it and use Patchbay for routing. Sounds difficult
if Alsa has only one recording source: "Mix".
That's the beauty of jack. You have your alsa in, patch it through
jack-rack running a reverb plugin (for example), and record that, or the
raw audio, or both.
and if anyone
has ideas for an elegant
automatic-module-placement solution
How about manual placement first? User could organize the modules
and then save the whole thing to file. When user loads the file,
the display looks the same -- and also all applications are launched.
If applications are launched from shell or if Patchbay figures out
the currently running Jack/Alsa system, then automatic placement would
be needed. But I would like to always build the system from scratch
or from file with Patchbay. Patchbay could recognize all new applications launched
from shell.
Usually one application is launched at a time and manual placement
is no problem.
Not true really, especially as LADCCA becomes more popular.
Again, the end result can be saved to file and there
is no need to redo the placement each time.
Patchbay files could be inserted to the current patchbay. E.g.,
a reverb patch could have four reverb related modules which together
makes the reverb. That is, four different Jack applications.
This doesn't have anything to do with the patch bay, but anyone who
implements a reverb like this should be taken out back and shot
regardless. ;) This is definately LADSPA-domain.
Inserted Patchbay files may need null nodes. If
multiple modules
needs the same input, then with the null node the inputs can be
combined.
Jack allows multiple connections.
You seem to consider the patch bay as much more of a "master"
application than myself. To me, the ideal patch bay is just there:
facilitates connections apps as nicely as possible, and displays the
current state of connection clearly.
You should definitely look into Jack and LADCCA - alot of your dreams
are already a reality. :)
Thanks for the suggestions..
-Dave