3 Nov
2004
3 Nov
'04
5:25 p.m.
dssi-vst 0.3 released!
======================
The 0.3 release of dssi-vst is now available.
dssi-vst is a DSSI plugin wrapper for VST effects and instruments
with GUI support, allowing them to be loaded into any DSSI host.
It requires a fairly recent version of Wine (this calendar year at least).
dssi-vst is available from the download page at
http://dssi.sourceforge.net/
The main improvement since the initial 0.1 release is that dssi-vst
now works correctly with plugins with complex GUIs that use
back-channel information to communicate things like patch data to
the audio plugin. In practical terms, this means that VSTs with
test keyboard widgets, patch load and save, and other natty features
in their GUIs should work properly as DSSI plugins without losing
automatability for the true automatable parameters.
3 Nov
3 Nov
6:05 p.m.
Hi,
I gotta stop living in a cave. I was unaware of dssi
until the release announcements from today. Great
stuff, thank you.
Happy me, just livin' in a cave
Watchin fishes jumpin high
Watchin clouds rolling by
Happy me, just livin' in a cave
Cleanin the guns for Jaaa
Four more years will go by
ron
--- Chris Cannam <cannam(a)all-day-breakfast.com> wrote:
dssi-vst 0.3 released!
======================
The 0.3 release of dssi-vst is now available.
dssi-vst is a DSSI plugin wrapper for VST effects
and instruments
with GUI support, allowing them to be loaded into
any DSSI host.
It requires a fairly recent version of Wine (this
calendar year at least).
dssi-vst is available from the download page at
http://dssi.sourceforge.net/
The main improvement since the initial 0.1 release
is that dssi-vst
now works correctly with plugins with complex GUIs
that use
back-channel information to communicate things like
patch data to
the audio plugin. In practical terms, this means
that VSTs with
test keyboard widgets, patch load and save, and
other natty features
in their GUIs should work properly as DSSI plugins
without losing
automatability for the true automatable parameters.
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
4 Nov
4 Nov
1:30 a.m.
On Wed, Nov 03, 2004 at 02:05:50PM -0800, R Parker wrote:
I gotta stop living in a cave. I was unaware of dssi
until the release announcements from today.
That is what release annoucements are for :)
DSSI was a bit low key before because it was still experimental, and some
of the unerlying software was a bit rough. But now its a really useful
format.
- Steve
11:36 a.m.
Chris Cannam wrote:
dssi-vst 0.3 released!
======================
The 0.3 release of dssi-vst is now available.
dssi-vst is a DSSI plugin wrapper for VST effects and instruments
with GUI support, allowing them to be loaded into any DSSI host.
It requires a fairly recent version of Wine (this calendar year at least).
dssi-vst is available from the download page at
http://dssi.sourceforge.net/
The main improvement since the initial 0.1 release is that dssi-vst
now works correctly with plugins with complex GUIs that use
back-channel information to communicate things like patch data to
the audio plugin. In practical terms, this means that VSTs with
test keyboard widgets, patch load and save, and other natty features
in their GUIs should work properly as DSSI plugins without losing
automatability for the true automatable parameters.
So in a brief outline, how do I use this? Is it a requirement that the
app supports it? Can I use it with RG and Muse? If so, how?
Thanks
R~
11:52 a.m.
On Thursday 04 Nov 2004 15:38, Russell Hanaghan wrote:
So in a brief outline, how do I use this? Is it a
requirement that
the app supports it? Can I use it with RG and Muse? If so, how?
You can use DSSI plugins directly in an app that supports hosting them,
such as Rosegarden. They should be picked up automatically in exactly
the same way as LADSPA plugins are. The app will need to have been
configured with DSSI support, however, and if it's a packaged version
it might not have been.
Alternatively, you can effectively turn any DSSI plugin into a
standalone JACK/ALSA-sequencer soft synth by using the jack-dssi-host
program provided with the DSSI distribution. This is a minimal host
that just runs the plugins named on the command line, providing JACK
inputs and outputs and ALSA sequencer MIDI input. This would allow you
to use (for example) the hexter DX7 synth with MusE.
jack-dssi-host is also capable of being invoked through a symbolic link:
if you create a link to it called /usr/bin/hexter (for example), then
when invoked via that link it will look for hexter.so and run the first
plugin found in it automatically. This means a plugin can be installed
both as a plugin (hexter.so) and as what looks like a true
ALSA-seq/JACK synth application (the hexter symbolic link).
Chris
11:57 a.m.
On Thursday 04 Nov 2004 16:03, Chris Cannam wrote:
On Thursday 04 Nov 2004 15:38, Russell Hanaghan
wrote:
Duh, I'm sorry -- I dozily misread which thread you were asking about,
and thought you were asking about DSSI plugins generally rather than
dssi-vst specifically.
dssi-vst is a DSSI plugin, so what I just wrote does apply to it. If
it's properly built and installed (which is generally the tricky bit!)
then it will scan the VST plugins found in $VST_PATH (defaulting to
$HOME/vst/) and make them all available to any DSSI host as DSSI
plugins. So they should show up automatically in e.g. Rosegarden.
To run them in a standalone mode, one can say something like
jack-dssi-host dssi-vst.so:Reaktor4.dll
to run a particular wrapped plugin using the reference host. This is
pretty much equivalent to using Kjetil's vsti program (from vstserver).
Chris
So in a brief outline, how do I use this? Is it a
requirement that
the app supports it? Can I use it with RG and Muse? If so, how?
You can use DSSI plugins directly in an app that supports hosting
them, such as Rosegarden. [...]
11:58 a.m.
Chris Cannam wrote:
On Thursday 04 Nov 2004 15:38, Russell Hanaghan wrote:
Great! Thanks Chris.
I use Thac's RPMS on MDK and I believe he did compile for dssi support
in RG at least.
I will check it out. I already have a fuctioning jack_fst on my system
so I'm going to assume DSSI will live with that and it's subsequent Wine
needs.
R~
So in a brief outline, how do I use this? Is it a
requirement that
the app supports it? Can I use it with RG and Muse? If so, how?
You can use DSSI plugins directly in an app that supports hosting them,
such as Rosegarden. They should be picked up automatically in exactly
the same way as LADSPA plugins are. The app will need to have been
configured with DSSI support, however, and if it's a packaged version
it might not have been.
Alternatively, you can effectively turn any DSSI plugin into a
standalone JACK/ALSA-sequencer soft synth by using the jack-dssi-host
program provided with the DSSI distribution. This is a minimal host
that just runs the plugins named on the command line, providing JACK
inputs and outputs and ALSA sequencer MIDI input. This would allow you
to use (for example) the hexter DX7 synth with MusE.
jack-dssi-host is also capable of being invoked through a symbolic link:
if you create a link to it called /usr/bin/hexter (for example), then
when invoked via that link it will look for hexter.so and run the first
plugin found in it automatically. This means a plugin can be installed
both as a plugin (hexter.so) and as what looks like a true
ALSA-seq/JACK synth application (the hexter symbolic link).
Chris
12:05 p.m.
On Thursday 04 Nov 2004 16:00, Russell Hanaghan wrote:
I will check it out. I already have a fuctioning
jack_fst on my system
so I'm going to assume DSSI will live with that and it's subsequent Wine
needs.
Yes, I think that should get you 90% of the way there.
btw, if you happen to be using gcc-3.4, it's been pointed out that the
vsthost.cpp file in dssi-vst won't compile without a small edit -- you need
to remove the "(0)" from the ends of lines 379 and 396. I'll probably do a
minor release to fix that (and only that) shortly.
Chris
12:15 p.m.
Chris Cannam wrote:
On Thursday 04 Nov 2004 16:00, Russell Hanaghan wrote:
So overall, and noting what your statement iludes to in this line of
thinking, what advantages might there be for the vst specific stuff in
running this client as opposed to jack_fst or vstserver?
For right now, the main vst plug I use is Edirols HyperCanvas. It's a
Kicka$$ GM2 softsynth which In my opinion nothing else touches in the
soundfont world. I have it running fairly stable and it is kind of a
turning point for me to have a good reliable GM or GS softsynth. When I
can get this, I can seriously look at dumoing CW Sonar on Winblows XP
altogether. But also as Austin said...They ALL work great at home and
crash at the most inopportune moments! :) Also Muse and RG need some
more work to be ready for primetime.
R~
I will check it out. I already have a fuctioning
jack_fst on my system
so I'm going to assume DSSI will live with that and it's subsequent Wine
needs.
Yes, I think that should get you 90% of the way there.
btw, if you happen to be using gcc-3.4, it's been pointed out that the
vsthost.cpp file in dssi-vst won't compile without a small edit -- you need
to remove the "(0)" from the ends of lines 379 and 396. I'll probably do a
minor release to fix that (and only that) shortly.
Chris
12:30 p.m.
On Thursday 04 Nov 2004 16:18, Russell Hanaghan wrote:
what advantages might there be for the vst specific
stuff in
running this client as opposed to jack_fst or vstserver?
The only really compelling reason is that you happen to want to use VST
effects or instruments as plugins in a DSSI host (which today means in
Rosegarden).
Another practical reason to use dssi-vst is that it's probably less particular
than jack_fst or vstserver about what versions of Wine it works with, but
that obviously isn't an issue for you. It is also possible that some VSTs
might work in dssi-vst but not in jack_fst or vstserver, and vice versa, just
because of subtle differences between the hosts, but that's just theory --
I'm not aware of any examples.
jack_fst will almost certainly offer lower latencies and better realtime
performance than either vstserver or dssi-vst.
Chris
1:04 p.m.
Chris Cannam wrote:
On Thursday 04 Nov 2004 16:18, Russell Hanaghan wrote:
That would be a big deal IMO! I spent a LONG time trying to get vst
stuff working. In the end, the only 2 versions of Wine that have worked
with jack_fst were the one on Kjetils site and the current version I'm
using which is 05052004.
what advantages might there be for the vst
specific stuff in
running this client as opposed to jack_fst or vstserver?
The only really compelling reason is that you happen to want to use VST
effects or instruments as plugins in a DSSI host (which today means in
Rosegarden).
Another practical reason to use dssi-vst is that it's probably less particular
than jack_fst or vstserver about what versions of Wine it works with, but
that obviously isn't an issue for you. It is also possible that some VSTs
might work in dssi-vst but not in jack_fst or vstserver, and vice versa, just
because of subtle differences between the hosts, but that's just theory --
I'm not aware of any examples.
jack_fst will almost certainly offer lower latencies
and better realtime
performance than either vstserver or dssi-vst.
This is a deal killer if the latency is significantly worse.
As soon as I get a chance I'll check it out.
Thanks!
Chris
1:20 p.m.
I have a hack that will allow you to run jack_fst with wine-20041019.
I would guess that the problem effects any method of running VSTs, but
I'd really like to get real info. It's a pretty simple hack that fixes
the problem in totally the wrong way, but if someone needs it get in
touch offline, or set up a web site where we can post the information
more globally.
- Mark
On Thu, 04 Nov 2004 09:06:35 -0800, Russell Hanaghan
<hanaghan(a)starband.net> wrote:
Chris Cannam wrote:
On Thursday 04 Nov 2004 16:18, Russell Hanaghan
wrote:
That would be a big deal IMO! I spent a LONG time trying to get vst
stuff working. In the end, the only 2 versions of Wine that have worked
with jack_fst were the one on Kjetils site and the current version I'm
using which is 05052004.
what advantages might there be for the vst
specific stuff in
running this client as opposed to jack_fst or vstserver?
The only really compelling reason is that you happen to want to use VST
effects or instruments as plugins in a DSSI host (which today means in
Rosegarden).
Another practical reason to use dssi-vst is that it's probably less particular
than jack_fst or vstserver about what versions of Wine it works with, but
that obviously isn't an issue for you. It is also possible that some VSTs
might work in dssi-vst but not in jack_fst or vstserver, and vice versa, just
because of subtle differences between the hosts, but that's just theory --
I'm not aware of any examples.
jack_fst will almost certainly offer lower
latencies and better realtime
performance than either vstserver or dssi-vst.
This is a deal killer if the latency is significantly worse.
As soon as I get a chance I'll check it out.
Thanks!
Chris
2:04 p.m.
Mark Knecht wrote:
I have a hack that will allow you to run jack_fst with
wine-20041019.
I would guess that the problem effects any method of running VSTs, but
I'd really like to get real info. It's a pretty simple hack that fixes
the problem in totally the wrong way, but if someone needs it get in
touch offline, or set up a web site where we can post the information
more globally.
- Mark
On Thu, 04 Nov 2004 09:06:35 -0800, Russell Hanaghan
<hanaghan(a)starband.net> wrote:
I don't use Wine for much else other than vst. Is there any other
advantages in running later Wine versions at this point? I did get
Cubase SX installed and even working! :) And EVEN with HyperCanvas no
less. A tad counterproductive though!
Chris Cannam wrote:
On Thursday 04 Nov 2004 16:18, Russell Hanaghan
wrote:
That would be a big deal IMO! I spent a LONG time trying to get vst
stuff working. In the end, the only 2 versions of Wine that have worked
with jack_fst were the one on Kjetils site and the current version I'm
using which is 05052004.
what advantages might there be for the vst
specific stuff in
running this client as opposed to jack_fst or vstserver?
The only really compelling reason is that you happen to want to use VST
effects or instruments as plugins in a DSSI host (which today means in
Rosegarden).
Another practical reason to use dssi-vst is that it's probably less particular
than jack_fst or vstserver about what versions of Wine it works with, but
that obviously isn't an issue for you. It is also possible that some VSTs
might work in dssi-vst but not in jack_fst or vstserver, and vice versa, just
because of subtle differences between the hosts, but that's just theory --
I'm not aware of any examples.
jack_fst will almost certainly offer lower
latencies and better realtime
performance than either vstserver or dssi-vst.
This is a deal killer if the latency is significantly worse.
As soon as I get a chance I'll check it out.
Thanks!
Chris
2:08 p.m.
On Thu, 04 Nov 2004 10:06:18 -0800, Russell Hanaghan
<hanaghan(a)starband.net> wrote:
I
don't use Wine for much else other than vst. Is there any other
advantages in running later Wine versions at this point? I did get
Cubase SX installed and even working! :) And EVEN with HyperCanvas no
less. A tad counterproductive though!
There is no reason to update that I can give you. You'd have to decide
that for yourself. If you have things working then I'd just leave it
alone. I had some non-music reasons to update and was tired of
switching between versions based on what I was running.
- Mark
12:18 p.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Thursday 04 Nov 2004 16:00, Russell Hanaghan
wrote:
While you're at it, it doesn't compile with gcc-2.95 either (due to
C99-style declarations in the middle of compound statements)...
cc -Wall -g3 -I../dssi -I/INSTALL/liblo/include/lo -c -o jack-dssi-host.o
jack-dssi-host.c
jack-dssi-host.c: In function `load':
jack-dssi-host.c:489: parse error before `char'
jack-dssi-host.c:490: `filePath' undeclared (first use in this function)
jack-dssi-host.c:490: (Each undeclared identifier is reported only once
jack-dssi-host.c:490: for each function it appears in.)
jack-dssi-host.c: In function `main':
jack-dssi-host.c:972: parse error before `char'
jack-dssi-host.c:973: `clientName' undeclared (first use in this function)
jack-dssi-host.c:1305: parse error before `int'
jack-dssi-host.c:1309: `port' undeclared (first use in this function)
jack-dssi-host.c:1309: `value' undeclared (first use in this function)
make[1]: *** [jack-dssi-host.o] Error 1
make[1]: Leaving directory `/y/src/dssi-0.9/jack-dssi-host'
make: *** [all] Error 2
Those are easily fixed.
--
joq
I will check it out. I already have a fuctioning
jack_fst on my system
so I'm going to assume DSSI will live with that and it's subsequent Wine
needs.
Yes, I think that should get you 90% of the way there.
btw, if you happen to be using gcc-3.4, it's been pointed out that the
vsthost.cpp file in dssi-vst won't compile without a small edit -- you need
to remove the "(0)" from the ends of lines 379 and 396. I'll probably do a
minor release to fix that (and only that) shortly.
12:25 p.m.
On Thursday 04 Nov 2004 16:18, Jack O'Quin wrote:
While you're at it, it doesn't compile with
gcc-2.95 either (due to
C99-style declarations in the middle of compound statements)...
Damn it, I hate the fact that C allows that now. I only ever do it by
accident (the C++ side of my brain taking over) and it bothers me that the
compiler no longer rejects it.
I don't suppose you could work up a patch for it? I will do it if you don't
have the time, but I don't have an old enough compiler to test it with so I
might miss something, being stupid and all.
Chris
2:40 p.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Thursday 04 Nov 2004 16:18, Jack O'Quin wrote:
While the language change is clearly an improvement, it's annoying
because portable programs still need to support the old compilers for
a few more years.
I'd think gcc-3.x would have an option to warn about this usage.
While you're at it, it doesn't compile
with gcc-2.95 either (due to
C99-style declarations in the middle of compound statements)...
Damn it, I hate the fact that C allows that now. I only ever do it by
accident (the C++ side of my brain taking over) and it bothers me that the
compiler no longer rejects it. I don't suppose you could work up a patch for it?
I will do it if you don't
have the time, but I don't have an old enough compiler to test it with so I
might miss something, being stupid and all.
Sure. This makes it compile cleanly on Debian woody. I have not run
any tests, yet.
diff -ruN -X /home/joq/bin/qdiff.exclude dssi-0.9/examples/trivial_sampler.c
dssi-0.9-gcc-2.95/examples/trivial_sampler.c
--- dssi-0.9/examples/trivial_sampler.c Fri Oct 22 10:05:11 2004
+++ dssi-0.9-gcc-2.95/examples/trivial_sampler.c Thu Nov 4 11:33:04 2004
@@ -446,8 +446,8 @@
}
} else {
for (i = 0; i < samples; ++i) {
- tmpSamples[0][i] = 0.0f;
int j;
+ tmpSamples[0][i] = 0.0f;
for (j = 0; j < info.channels; ++j) {
tmpSamples[0][i] += tmpFrames[i * info.channels + j];
}
diff -ruN -X /home/joq/bin/qdiff.exclude dssi-0.9/fluidsynth-dssi/Makefile
dssi-0.9-gcc-2.95/fluidsynth-dssi/Makefile
--- dssi-0.9/fluidsynth-dssi/Makefile Mon Nov 1 13:37:35 2004
+++ dssi-0.9-gcc-2.95/fluidsynth-dssi/Makefile Thu Nov 4 12:24:02 2004
@@ -16,7 +16,7 @@
# 3. Adjust anything here as needed:
-OPTIMIZATION_CFLAGS = -O2 -s -fomit-frame-pointer -funroll-loops -ffast-math
-finline-functions -finline-limit=5000 -minline-all-stringops -Winline
+OPTIMIZATION_CFLAGS = -O2 -s -fomit-frame-pointer -funroll-loops -ffast-math
-finline-functions -Winline
PLUGIN_CFLAGS = -Wall -I. -I../dssi -I$(FLUID_INCLUDE) -I$(FLUID_SRC)
$(OPTIMIZATION_CFLAGS)
PLUGIN_LDFLAGS = -nostartfiles -shared
diff -ruN -X /home/joq/bin/qdiff.exclude dssi-0.9/jack-dssi-host/jack-dssi-host.c
dssi-0.9-gcc-2.95/jack-dssi-host/jack-dssi-host.c
--- dssi-0.9/jack-dssi-host/jack-dssi-host.c Tue Nov 2 08:14:49 2004
+++ dssi-0.9-gcc-2.95/jack-dssi-host/jack-dssi-host.c Thu Nov 4 11:32:16 2004
@@ -473,6 +473,8 @@
while ((element = strtok(path, ":")) != 0) {
+ char *filePath;
+
path = 0;
if (element[0] != '/') {
@@ -486,7 +488,7 @@
fprintf(stderr, "%s: Looking for library \"%s\" in %s... ",
myName, dllName, element);
}
- char *filePath = (char *)malloc(strlen(element) + strlen(dllName) + 2);
+ filePath = (char *)malloc(strlen(element) + strlen(dllName) + 2);
sprintf(filePath, "%s/%s", element, dllName);
if ((handle = dlopen(filePath, RTLD_NOW))) { /* real-time programs should not use
RTLD_LAZY */
@@ -687,6 +689,7 @@
char *url;
int i, reps, j;
int in, out, controlIn, controlOut;
+ char clientName[33];
setsid();
sigemptyset (&_signals);
@@ -969,7 +972,6 @@
/* Create buffers and JACK client and ports */
- char clientName[33];
if (instance_count > 1) strcpy(clientName, "jack-dssi-host");
else {
strncpy(clientName, plugin->descriptor->LADSPA_Plugin->Name, 32);
@@ -1301,9 +1303,9 @@
for (i = 0; i < controlInsTotal; ++i) {
if (pluginPortUpdated[i]) {
- instance = pluginControlInInstances[i];
int port = pluginControlInPortNumbers[i];
float value = pluginControlIns[i];
+ instance = pluginControlInInstances[i];
pluginPortUpdated[i] = 0;
if (instance->uiTarget) {
lo_send(instance->uiTarget, instance->ui_osc_control_path, "if",
port, value);
--
joq
5:14 p.m.
On Thu, Nov 04, 2004 at 12:40:07PM -0600, Jack O'Quin wrote:
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
Yes, so would I, I think it should do it if you specify --std=c89, but it
doesn't seem to. There may be some -W flag I've missed.
- Steve
On Thursday 04 Nov 2004 16:18, Jack O'Quin
wrote:
While the language change is clearly an improvement, it's annoying
because portable programs still need to support the old compilers for
a few more years.
I'd think gcc-3.x would have an option to warn about this usage. While you're at it, it doesn't compile
with gcc-2.95 either (due to
C99-style declarations in the middle of compound statements)...
Damn it, I hate the fact that C allows that now. I only ever do it by
accident (the C++ side of my brain taking over) and it bothers me that the
compiler no longer rejects it.
5:56 a.m.
New subject: [linux-audio-user] Ardour, Muse 7.0, Jack_fst (Hypercanvas) & Jack transport...
Hi all,
I know this isn't a big deal to most but I had to write and say...
With the Missus and kids out of town for a few...I've been a messin'
with Linux Audio! I have been thinking I was limited to audio only
recording with Ardour in Linux which was fine. But tonight I proved
myself wrong and also need to correct a few statements I've made previously.
I managed to sync Muse with Ardour and run a midi vst softsynth all with
relatively few glitches. Hypercanvas is a GM2 full instrument set (128 +
Roland variations) and has some killer sounds. I use midi sequences for
backing in my live stuff and play guitars and do vocals. Sort of
Kar-e-okie on steriods really...but it has punch! I have been needing to
do a demo so rather than concede defeat and resort to Sonar I tried this
combo and it worked very well. I actually finished on song and mastered
it thru Jamin and it kix ass even if I do say so myself!! :) I did
Superstition ...sort of a cross between Stevie and Stevie. The midi file
is very punchy and I laid 4 guitar tracks and 2 vocals. Never went out
of sync. Shut both progs down...shut one down...logged out on one
machine...oh...and for added kix, I used a laptop with 2 monitor capable
Vid card, hooked up a spare monitor and used XDMCP as well as a montor
and keyboard on the actual machine. This gave me twice as much Desktop
real estate and worked great! All stayed in sync with no drift at all.
Hypercanvas dies every so often but it was doing that before anyway.
So to correct the things I mentioned...Originally I said on this forum
that Muse was kind buggy and not ready for much of anything. Although
it's still very sensitive to loading up (used $ muse -P 99) and it does
not save mixer states (might be a controller thing in the sequence
too...I'm not sure) and still gets gas sometimes running on 2.6.7 with
realtime-lsm, it ran quite predictably and the thing I like about it
most is it is more intuitive than RG on instruments, etc. RG is a pain
because you have to setup instruments individually most of the time.
Sorry for the blurb...I gotta go to bed but I laid down 3 songs tonight
all in Linux and I'm stoked! I used the gammit and this is just
reaffrimation of what you all know; Linux audio has come a LONG way and
is packing some punch!!
Cheers
R~
7 Nov
7 Nov
9:15 a.m.
New subject: [linux-audio-user] Ardour, Muse 7.0, Jack_fst (Hypercanvas) & Jack transport...
Hi Russel,
fredagen den 5 november 2004 10.59 skrev Russell Hanaghan:
Hi all,
I know this isn't a big deal to most but I had to write and say...
With the Missus and kids out of town for a few...I've been a messin'
with Linux Audio! I have been thinking I was limited to audio only
recording with Ardour in Linux which was fine. But tonight I proved
myself wrong and also need to correct a few statements I've made
previously.
I managed to sync Muse with Ardour and run a midi vst softsynth all with
relatively few glitches. Hypercanvas is a GM2 full instrument set (128 +
Roland variations) and has some killer sounds. I use midi sequences for
backing in my live stuff and play guitars and do vocals. Sort of
Kar-e-okie on steriods really...but it has punch! I have been needing to
do a demo so rather than concede defeat and resort to Sonar I tried this
combo and it worked very well. I actually finished on song and mastered
it thru Jamin and it kix ass even if I do say so myself!! :) I did
Superstition ...sort of a cross between Stevie and Stevie. The midi file
is very punchy and I laid 4 guitar tracks and 2 vocals. Never went out
of sync. Shut both progs down...shut one down...logged out on one
machine...oh...and for added kix, I used a laptop with 2 monitor capable
Vid card, hooked up a spare monitor and used XDMCP as well as a montor
and keyboard on the actual machine. This gave me twice as much Desktop
real estate and worked great! All stayed in sync with no drift at all.
Good to hear that you are able to be creative in a Linux environment :)
Hypercanvas dies every so often but it was doing that
before anyway.
As for hypercanvas dying. I believe VST's must still be considered
experimental on Linux...
I've noticed that some of the synths are noticeable more stable if you close
it's GUI, you could give it a try. Please note that you can currently only do
this from the "Soft Synth Configuration" dialog, click on the corresponding
little green dot.
So to correct the things I mentioned...Originally I
said on this forum
that Muse was kind buggy and not ready for much of anything. Although
it's still very sensitive to loading up (used $ muse -P 99) and it does
not save mixer states
Actually all mixer states are properly stored but for some songs the mixer
states are overwritten with default values when the song has been loaded.
Somekind of a race condition that hasn't been properly investigated yet
(I think it's fixed for the coming 0.8, though that won't be out for a while).
You could try to load the song from command line this has helped for me on
many occasions.
(might be a controller thing in the sequence
too...I'm not sure) and still gets gas sometimes running on 2.6.7 with
realtime-lsm, it ran quite predictably and the thing I like about it
most is it is more intuitive than RG on instruments, etc. RG is a pain
because you have to setup instruments individually most of the time.
Sorry for the blurb...I gotta go to bed but I laid down 3 songs tonight
all in Linux and I'm stoked! I used the gammit and this is just
reaffrimation of what you all know; Linux audio has come a LONG way and
is packing some punch!!
Yep, making music under linux works (without bending over backwards) today!
Regards,
Robert
Cheers
R~
--
http://spamatica.se/music/
4 Nov
4 Nov
1:11 p.m.
On Thu, Nov 04, 2004 at 04:03:20PM +0000, Chris Cannam wrote:
jack-dssi-host is also capable of being invoked
through a symbolic link:
if you create a link to it called /usr/bin/hexter (for example), then
when invoked via that link it will look for hexter.so and run the first
plugin found in it automatically. This means a plugin can be installed
both as a plugin (hexter.so) and as what looks like a true
ALSA-seq/JACK synth application (the hexter symbolic link).
Now that is a neat hack.
--
Paul Winkler
http://www.slinkp.com
7350
days inactive
7354
days old
linux-audio-user@lists.linuxaudio.org
21 comments
8 participants
participants (8)
-
Chris Cannam -
Jack O'Quin -
Mark Knecht -
Paul Winkler -
R Parker -
Robert Jonsson -
Russell Hanaghan -
Steve Harris