22 Jan
2003
22 Jan
'03
4:01 a.m.
The SooperLooper LADSPA plugin now comes with PD patches!
For those that might not remember, SooperLooper is a LADSPA plugin that
emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get
more info and download it at its new address:
http://essej.net/sooperlooper/
See the screenshot of the PD patches in action here:
http://essej.net/sooperlooper/sooperlooper_pd_shot.png
It is controllable via the PD GUI or MIDI program change messages
from your footcontroller (the ideal interface).
Unfortunately, there are bugs in the plugin~-0.2 external that seems to
be around. I made a source patch that fixes the output control message
bugs, and extended them to include the output control port index as well.
You will need this patched version of plugin~ to run SooperLooper in PD
properly.
Get the patch here:
http://essej.net/sooperlooper/pd-plugin0.2-patch.diff
If someone on the pd-devel list could forward this, I would much
appreciate it.
Dave Phillips, could you also update the web address on your LM&S pages
with the new address above?
Enjoy... please post with any problems/suggestions.
jlc
22 Jan
22 Jan
3:06 p.m.
Hi Jesse,
I've CC'd the pd list and I am going to include the patches in the
PD external CVS. Last time I tried to contact
Jarno Sepp<E4>nen <jams(a)cs.tut.fi> the email bounced.
Anyone knows Jarno's new address ?
Sooperlooper looks cooool :)
Greetings,
Guenter
On Wed, 22 Jan 2003, Jesse Chappell wrote:
The SooperLooper LADSPA plugin now comes with PD
patches!
For those that might not remember, SooperLooper is a LADSPA plugin that
emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get
more info and download it at its new address:
http://essej.net/sooperlooper/
See the screenshot of the PD patches in action here:
http://essej.net/sooperlooper/sooperlooper_pd_shot.png
It is controllable via the PD GUI or MIDI program change messages
from your footcontroller (the ideal interface).
Unfortunately, there are bugs in the plugin~-0.2 external that seems to
be around. I made a source patch that fixes the output control message
bugs, and extended them to include the output control port index as well.
You will need this patched version of plugin~ to run SooperLooper in PD
properly.
Get the patch here:
http://essej.net/sooperlooper/pd-plugin0.2-patch.diff
If someone on the pd-devel list could forward this, I would much
appreciate it.
Dave Phillips, could you also update the web address on your LM&S pages
with the new address above?
Enjoy... please post with any problems/suggestions.
jlc
3:09 p.m.
The SooperLooper LADSPA plugin now comes with PD
patches!
For those that might not remember, SooperLooper is a LADSPA plugin that
emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get
yes, its totally awesome, as awesome as every automatically built GUI
for this plugin is unusable :)
so, who would like to volunteer to write a JACK client that runs the
plugin and provides a decent GUI for it?
--p
3:41 p.m.
IMHO, a fancy GUI for a real time effect like this one is a bit of a
wasted effort. You typically use this thing from your geetar and a pedal
board that sends program change messages. With the PD front end, you can
replace the pedal board with anything, including results of audio
analysis (i.e. "start recording when you hear me play above A5", "match
your loop length to this drum track".). One doesn't ever really clicky
on the "RECORD" button with this from the console.
It might be nice if this sort of functionality melded into ssm, where
you could see the loop displayed around the circle... There would be a
visual cue then for when the loop was about to repeat, which can be hard
to find when the loop is > 10s long...
But at that point, we're adding features to the virtual edp, and we
haven't even covered all the "loop IV" firmware features yet...
On Wed, 2003-01-22 at 14:06, Paul Davis wrote:
The
SooperLooper LADSPA plugin now comes with PD patches!
For those that might not remember, SooperLooper is a LADSPA plugin that
emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get
yes, its totally awesome, as awesome as every automatically built GUI
for this plugin is unusable :)
so, who would like to volunteer to write a JACK client that runs the
plugin and provides a decent GUI for it?
--p
4:56 p.m.
jfm3 wrote on Wed, 22-Jan-2003:
IMHO, a fancy GUI for a real time effect like this one
is a bit of a
wasted effort. You typically use this thing from your geetar and a pedal
board that sends program change messages.
I tend to agree with jfm3 here... the EDP featureset and interface was pretty
much designed expressly for realtime live use.
Other looping paradigms might be more powerful and appropriate
for computer UI interaction and sequencing... and I'm sure one
of us will get something jacked into Ardour eventually :)
On another note -- if anyone gets sooperlooper (via PD or anything
else) working on a Mac, let me know because Matthias Grob
(the designer of the original EDP) has expressed interest in using
it.
jlc
7:23 p.m.
IMHO, a fancy GUI for a real time effect like this one
is a bit of a
wasted effort. You typically use this thing from your geetar and a pedal
geetar? don't got no steenkin geetar. jus me an' mah old iron ufo
drum, the latest toy to spend time here in the studio. the most fun
you can have with all 10 fingers. its an inverted steel drum, a nipple
gong and on the other side, a steel udu. *this* is what i want to do
loops with. http://www.hang.ch/
board that sends program change messages. With the PD
front end, you can
replace the pedal board with anything, including results of audio
analysis (i.e. "start recording when you hear me play above A5", "match
your loop length to this drum track".). One doesn't ever really clicky
on the "RECORD" button with this from the console.
ok. uncle.
but hey, can we have a jMax object too? pretty please?
It might be nice if this sort of functionality melded
into ssm, where
you could see the loop displayed around the circle... There would be a
visual cue then for when the loop was about to repeat, which can be hard
to find when the loop is > 10s long...
nice point.
23 Jan
23 Jan
5:49 a.m.
It might be nice if this sort of functionality melded
into ssm, where
you could see the loop displayed around the circle... There would be a
visual cue then for when the loop was about to repeat, which can be hard
to find when the loop is > 10s long...
Yes, this is like dream land. I've been thinking of a way of squeezing
enough spiral loops type displays onto a screen so that I can watch 4+
loops at once.
You either make them side by side, and they all have to be small or make
them coaxial, but then one is small and one is huge.
Spiral Loops is just the most natural way to work with synced loops.
- Steve
6:35 a.m.
On Thu, 23 Jan 2003 09:43:01 +0000, Steve Harris wrote
I can have a go at making them resizable if you like. I'm probably going to
write a new spiral loop plugin for ssm soon. The fltk widget can be released
seperately if people are interested.
Dave
It might be
nice if this sort of functionality melded into ssm, where
you could see the loop displayed around the circle... There would be a
visual cue then for when the loop was about to repeat, which can be hard
to find when the loop is > 10s long...
Yes, this is like dream land. I've been thinking of a way of
squeezing enough spiral loops type displays onto a screen so that I
can watch 4+ loops at once.
You either make them side by side, and they all have to be small or make
them coaxial, but then one is small and one is huge.
Spiral Loops is just the most natural way to work with synced loops.
6:59 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] sooperlooper goes PD
On Thu, Jan 23, 2003 at 11:28:32 +0100, Dave Griffiths wrote:
That would be cool, but SpiralLoops could do with a few more looping
features too, to bring it up to the usefullness of an Echoplex. I can mail
a list to the -user list if you want :)
Actually if theres a piece of JACK software than can just do dumb loop
playing and crossfading and can send MIDI Clock at every loop sync point
that will save me a couple of hours of hacking.
- Steve
Spiral Loops
is just the most natural way to work with synced loops.
I can have a go at making them resizable if you like. I'm probably going to
write a new spiral loop plugin for ssm soon. The fltk widget can be released
seperately if people are interested.
7:31 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] sooperlooper goes PD
On Thu, 23 Jan 2003 10:52:18 +0000, Steve Harris wrote
On Thu, Jan 23, 2003 at 11:28:32 +0100, Dave Griffiths
wrote:
That would be cool, but SpiralLoops could do with a few more looping
features too, to bring it up to the usefullness of an Echoplex. I
can mail a list to the -user list if you want :)
yes please - I'm also thinking of adding some granulation features, auto
percussion hit detection/shuffling (like recycle) etc.
dave
Spiral
Loops is just the most natural way to work with synced loops.
I can have a go at making them resizable if you like. I'm probably going to
write a new spiral loop plugin for ssm soon. The fltk widget can be released
seperately if people are interested. 
12:04 p.m.
On Thu, 2003-01-23 at 00:20, Paul Davis wrote:
AFAIK, sooperlooper is a LADSPA plugin that is wrapped inside a PD
object using plugin~. So we need to do plugin~ for jMax. It is in the
TODO list, but first we finish the JACK support and output a 4.0.1
release with it (it is already in the cvs version). I think that within
one month we should have both ladspa inside jMax and jMax inside ladspa
(running a patch as a plugin).
François
IMHO, a fancy
GUI for a real time effect like this one is a bit of a
wasted effort. You typically use this thing from your geetar and a pedal
geetar? don't got no steenkin geetar. jus me an' mah old iron ufo
drum, the latest toy to spend time here in the studio. the most fun
you can have with all 10 fingers. its an inverted steel drum, a nipple
gong and on the other side, a steel udu. *this* is what i want to do
loops with. http://www.hang.ch/
board that sends program change messages. With the
PD front end, you can
replace the pedal board with anything, including results of audio
analysis (i.e. "start recording when you hear me play above A5", "match
your loop length to this drum track".). One doesn't ever really clicky
on the "RECORD" button with this from the console.
ok. uncle.
but hey, can we have a jMax object too? pretty please?
12:46 p.m.
On Thu, 2003-01-23 at 17:15, Paul Davis wrote:
To run a patch as a LADSPA plugin, there will a generic jMax plugin that
loads the patch and wraps the jMax calls inside LADSPA calls (mainly the
. The LADSPA ports will be mapped to control busses inside the patch.
The control busses can handle any type of values (even objects...), but
what will be visible from a LADSPA point of view will be the LADSPA
types, i.e. floats.
Did I understood the question ?
fd
one month we
should have both ladspa inside jMax and jMax inside ladspa
(running a patch as a plugin).
oh my. no string parameters, though, true?
1:06 p.m.
On Thu, Jan 23, 2003 at 05:39:27 +0100, Francois Dechelle wrote:
I'm guessing that Paul was wondering how you tell the LADSPA plugin what
jMax patch to load. Well, thats what I'm wondering anyway ;)
- Steve
oh my. no
string parameters, though, true?
To run a patch as a LADSPA plugin, there will a generic jMax plugin that
loads the patch and wraps the jMax calls inside LADSPA calls (mainly the
. The LADSPA ports will be mapped to control busses inside the patch.
The control busses can handle any type of values (even objects...), but
what will be visible from a LADSPA point of view will be the LADSPA
types, i.e. floats.
Did I understood the question ?
2:07 p.m.
Steve Harris wrote:
The 2 questions are related.
Is the output a .c file that can be compiled to to
make a LADSPA plugin
(presumably linked against FTS), or is there an uber plugin that can load
any jMax patch?
For former would be more interesting I think, but both are very cool.
My idea was the first one, i.e. produce a .c (or a .so) that contains
the patch in the data section. This will be in turn linked to libfts.so.
I'm guessing that Paul was wondering how you tell
the LADSPA plugin what
jMax patch to load. Well, thats what I'm wondering anyway ;)
If the patch is included in the .c, then you tell it when building the
plugin.
François
4:34 p.m.
On Thu, 2003-01-23 at 18:02, François Déchelle wrote:
Could you not do something similar to the vst plugin? Ie, have an
LADSPA_JMAX_PATH, or something, that has directories containing patches,
and have the ladspa .so build its list of plugins from scanning these
directories? I don't know anything about jmax; is there something that
stops this from working?
Bob
I'm
guessing that Paul was wondering how you tell the LADSPA plugin what
jMax patch to load. Well, thats what I'm wondering anyway ;)
If the patch is included in the .c, then you tell it when building the
plugin.
24 Jan
24 Jan
9:10 a.m.
On Thu, 2003-01-23 at 21:23, Bob Ham wrote:
On Thu, 2003-01-23 at 18:02, François Déchelle wrote:
Could you not do something similar to the vst plugin? Ie, have an
LADSPA_JMAX_PATH, or something, that has directories containing patches,
and have the ladspa .so build its list of plugins from scanning these
directories? I don't know anything about jmax; is there something that
stops this from working?
Bob
But even using this, you still have to pass to the plugin the name of
the patch to be loaded, in case there are several patches (i.e. .jmax
files) in the LADSPA_JMAX_PATH directories ?
fd
I'm
guessing that Paul was wondering how you tell the LADSPA plugin what
jMax patch to load. Well, thats what I'm wondering anyway ;)
If the patch is included in the .c, then you tell it when building the
plugin.
25 Jan
25 Jan
3:20 p.m.
On Fri, 2003-01-24 at 13:03, Francois Dechelle wrote:
I think there's some confusion here, so I'll be very specific. In the
.so, the _init function would go through each patch file in each
directory and extract the information about them (eg, name, port
descriptors, etc) and build its list of ladspa descriptors from this
information. The host interrogates this list, says "instantiate plugin
X" and the plugin would (some how) load the patch in jmax.
Where am I going wrong?
Bob
Could you not
do something similar to the vst plugin? Ie, have an
LADSPA_JMAX_PATH, or something, that has directories containing patches,
and have the ladspa .so build its list of plugins from scanning these
directories? I don't know anything about jmax; is there something that
stops this from working?
But even using this, you still have to pass to the plugin the name of
the patch to be loaded, in case there are several patches (i.e. .jmax
files) in the LADSPA_JMAX_PATH directories ?
27 Jan
27 Jan
5 a.m.
On Sat, 2003-01-25 at 20:06, Bob Ham wrote:
I think there's some confusion here, so I'll be very specific. In the
.so, the _init function would go through each patch file in each
directory and extract the information about them (eg, name, port
descriptors, etc) and build its list of ladspa descriptors from this
information. The host interrogates this list, says "instantiate plugin
X" and the plugin would (some how) load the patch in jmax.
Where am I going wrong?
Bob
You're 100% right, it's the right way to do it. Moreover, this does not
prevent at all from embedding a patch into a .so, which still can be
useful.
François
23 Jan
23 Jan
1:05 p.m.
On Thu, Jan 23, 2003 at 11:15:27 -0500, Paul Davis wrote:
Is the output a .c file that can be compiled to to make a LADSPA plugin
(presumably linked against FTS), or is there an uber plugin that can load
any jMax patch?
For former would be more interesting I think, but both are very cool.
- Steve
one month we
should have both ladspa inside jMax and jMax inside ladspa
(running a patch as a plugin).
oh my. no string parameters, though, true?
7961
days inactive
7966
days old
linux-audio-dev@lists.linuxaudio.org
19 comments
8 participants
participants (8)
-
Bob Ham -
Dave Griffiths -
Francois Dechelle -
guenter geiger -
Jesse Chappell -
jfm3 -
Paul Davis -
Steve Harris