17 Oct
2002
17 Oct
'02
5:56 p.m.
Guys,
This answer appeared just after I decided to ask the very same question.
Is it true that there is no _common_ "instrument" or "synth" plugin
API on linux?
Is it true that there is no the same kind of media for out-of-process instruments?
I see that there are some kinds of possible plugin APIs:
-- MusE's LADSPA extensions
-- mustajuuri plugin
-- maybe there's some more (MAIA? OX?)
-- I remember Juan Linietsky working on binding sequencer with softsynths
But I dont remember to hear anything about the results
So can anyone _please_ answer:
What is the right way to use the multiple (e.g. thirty)
softsynths together simultaneously with one host?
I mean working completely inside my computer
to have just one (or even none) midi keyboard as input.
So all the synthesys, mixing, processing goes on inside.
And to send one audio channel out to any sound card.
thanks,
nikodimka
=======8<==== Tommi Ilmonen wrote: ===8<=================
Hi.
Sorry to come in very late. The Mustajuuri plugin interface includes all
the bits you need. In fact I already have two synthesizer engines under
the hood.
With Mustajuuri you can write the synth as a plugin and the host is only
responsible for delivering the control messages to it.
Alternatively you could write a new voice type for the Mustajuuri synth,
which can lead to smaller overhead ... or not, depending on what you are
after.
http://www.tml.hut.fi/~tilmonen/mustajuuri/
On 3 Jul 2002, nick wrote:
Hi all
I've been scratching my head for a while now, planning out how im going
to write amSynthe (aka amSynth2)
Ideally i don't want to be touching low-level stuff again, and it makes
sense to write it as a plugin for some host. Obviously in the Win/Mac
world theres VST/DXi/whatever - but that doesnt really concern me as I
dont use em ;) I just want to make my music on my OS of choice..
Now somebody please put me straight here - as far as I can see, there's
LADSPA and JACK. (and MuSE's own plugins?). Now, I'm under the
impression that these only deal with the audio data - only half what I
need for a synth. Or can LADSPA deal with MIDI?
So how should I go about it?
Is it acceptable to (for example) read the midi events from the ALSA
sequencer in the audio callback? My gut instinct is no, no, no!
Even if that's feasible with the alsa sequencer, it still has problems -
say the host wanted to "render" the `song' to an audio file - using the
sequencer surely it would have to be done in real time?
I just want to get on, write amSynthe and then everyone can enjoy it,
but this hurdle is bigger than it seems.
Thanks,
Nick
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Tommi Ilmonen Researcher
Linux/IRIX
audio: Mustajuuri
3D audio/animation: DIVA
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
17 Oct
17 Oct
6:45 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real "instrument" or "synth" plugin API. but since my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
along the way)
Although in light of Tommi's post (mastajuuri) i have to reconsider
working on my API. My only problem with mastajuuri is its dependance on
QT (if im not mistaken), sorry.
If people would like to my work-in-progress, i could definitely use some
feedback ;-)
This discussion is open!
-Nick
On Thu, 2002-10-17 at 20:53, nikodimka wrote:
Guys,
This answer appeared just after I decided to ask the very same question.
Is it true that there is no _common_ "instrument" or "synth" plugin
API on linux?
Is it true that there is no the same kind of media for out-of-process instruments?
I see that there are some kinds of possible plugin APIs:
-- MusE's LADSPA extensions
-- mustajuuri plugin
-- maybe there's some more (MAIA? OX?)
-- I remember Juan Linietsky working on binding sequencer with softsynths
But I dont remember to hear anything about the results
So can anyone _please_ answer:
What is the right way to use the multiple (e.g. thirty)
softsynths together simultaneously with one host?
I mean working completely inside my computer
to have just one (or even none) midi keyboard as input.
So all the synthesys, mixing, processing goes on inside.
And to send one audio channel out to any sound card.
thanks,
nikodimka
=======8<==== Tommi Ilmonen wrote: ===8<=================
Hi.
Sorry to come in very late. The Mustajuuri plugin interface includes all
the bits you need. In fact I already have two synthesizer engines under
the hood.
With Mustajuuri you can write the synth as a plugin and the host is only
responsible for delivering the control messages to it.
Alternatively you could write a new voice type for the Mustajuuri synth,
which can lead to smaller overhead ... or not, depending on what you are
after.
http://www.tml.hut.fi/~tilmonen/mustajuuri/
On 3 Jul 2002, nick wrote:
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Hi all
I've been scratching my head for a while now, planning out how im going
to write amSynthe (aka amSynth2)
Ideally i don't want to be touching low-level stuff again, and it makes
sense to write it as a plugin for some host. Obviously in the Win/Mac
world theres VST/DXi/whatever - but that doesnt really concern me as I
dont use em ;) I just want to make my music on my OS of choice..
Now somebody please put me straight here - as far as I can see, there's
LADSPA and JACK. (and MuSE's own plugins?). Now, I'm under the
impression that these only deal with the audio data - only half what I
need for a synth. Or can LADSPA deal with MIDI?
So how should I go about it?
Is it acceptable to (for example) read the midi events from the ALSA
sequencer in the audio callback? My gut instinct is no, no, no!
Even if that's feasible with the alsa sequencer, it still has problems -
say the host wanted to "render" the `song' to an audio file - using the
sequencer surely it would have to be done in real time?
I just want to get on, write amSynthe and then everyone can enjoy it,
but this hurdle is bigger than it seems.
Thanks,
Nick
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Tommi Ilmonen Researcher
Linux/IRIX audio: Mustajuuri
3D audio/animation: DIVA
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com 
7 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
IMO running each synth in its own thread with many
synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
i think you need to scan back a year or 18 months in the archives to
where we measured this. the context switch under linux can be
extremely quick - on the order of 20-50 usecs on a PII-450, and is not
necessarily a problem. switching between contexts is massively more
expensive under windows and macos (at least pre-X), and hence the
multi-process design is not and cannot be an option for them at this time.
No, there is no real "instrument" or
"synth" plugin API. but since my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
along the way)
thus guaranteeing that no instruments can be written in other
languages. for all the mistakes the GTK+ crew made, their design to
use C as the base language so as to allow for other languages to
provide "wrappers" was a far-sighted and wise choice. OTOH, i will
concede that the real-time nature of most synthesis would tend to rule
out most of the languages of interest.
Although in light of Tommi's post (mastajuuri) i
have to reconsider
working on my API. My only problem with mastajuuri is its dependance on
QT (if im not mistaken), sorry.
If people would like to my work-in-progress, i could definitely use some
feedback ;-)
This discussion is open!
the discussion is several years old :)
you managed to touch upon the central problem in your penultimate
sentence, apparently without realizing the depth of the problem.
if a synth comes with a GUI, then the issue of toolkit compatibility
rears its ugly and essentially insoluble head once again. you can't
put GTK based code into a Qt application, or vice versa. this also
fails with any combination of toolkits, whether they are fltk, xforms,
motif etc. etc.
if the synth doesn't come with a GUI, but runs in the same process as
the host, then every synth has to have some kind of inter-process
control protocol to enable a GUI to control it.
these are deep problems that arise from the lack of a single toolkit
on linux (and unix in general).
this is why JACK is designed in the way that it is, and why it
(theoretically) allows for both in-process and out-of-process
"plugins". this allows programmers to choose which model they want to
use. i predict that any API that forces the programmer to use a
particular toolkit will fail. JACK's problem in this arena is that its
designed for sharing audio data, and does not provide any method for
sharing MIDI or some other protocol to control synthesis parameters.
besides, if SC for linux is in the offing, who needs any other
synthesizers anyway? :))
--p
18 Oct
18 Oct
6:33 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Thu, Oct 17, 2002 at 05:00:39 -0400, Paul Davis wrote:
i think you need to scan back a year or 18 months in
the archives to
where we measured this. the context switch under linux can be
extremely quick - on the order of 20-50 usecs on a PII-450, and is not
Do we know if this is getting better or worse? My experince of large cache
Xeons is that they context switch very slowly (compared with PII's of the
same generation). Whats the switch time on P4's and AthlonXP's like?
this is why JACK is designed in the way that it is,
and why it
(theoretically) allows for both in-process and out-of-process
"plugins". this allows programmers to choose which model they want to
use. i predict that any API that forces the programmer to use a
particular toolkit will fail. JACK's problem in this arena is that its
Which raises another important point, IMHO any softsynth API that wasn't
jack backed would have to have some pretty good reasons.
- Steve
3:34 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
This discussion
is open!
the discussion is several years old :) you managed to touch upon the central problem in your
penultimate
sentence, apparently without realizing the depth of the problem.
if a synth comes with a GUI, then the issue of toolkit compatibility
rears its ugly and essentially insoluble head once again. you can't
put GTK based code into a Qt application, or vice versa. this also
fails with any combination of toolkits, whether they are fltk, xforms,
motif etc. etc.
if the synth doesn't come with a GUI, but runs in the same process as
the host, then every synth has to have some kind of inter-process
control protocol to enable a GUI to control it.
but personally i find it much more desirable that the plugin provides
effectively a widget which can be added to a container (provided by the
host) rather than the plugin creating its own window. its just much
neater..
I thought Gtk(mm) is a more natural choice, since it is freely available
on all platforms, voila.
these are deep problems that arise from the lack of a
single toolkit
on linux (and unix in general).
:-/
--p
-nick
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
4:16 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
but personally i find it much more desirable that the
plugin provides
effectively a widget which can be added to a container (provided by the
host) rather than the plugin creating its own window. its just much
neater..
this makes no difference to the problem. whether the plugin creates a
widget or a window, the integration of the event loop is still a
central blocking problem.
I thought Gtk(mm) is a more natural choice, since it is
freely available
on all platforms, voila.
many Qt users feel otherwise. and wxWin is available too, along with
several other kits.
--p
19 Oct
19 Oct
4:51 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Fri, 2002-10-18 at 11:16, Paul Davis wrote:
Please enlighten me, what was the problem then with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
It seems like something of this nature should be implemented at a layer
above the GUI toolkit, like the window manager for example. If there was
a way to layout multiple X windows (interface elements) on a single
window and be able to edit their dimensions, manage placement, etc, GUI
toolkit would not matter so much. This also seems to kind of tie back
into the metadata/session storage discussion that was going on before. I
like the idea of multiple programs working together in a Linux
music/audio session, but I can forsee the nightmare of having dozens of
windows scattered all over the desktop.
GTK doesn't support as many platforms as I would like (although I use it
with Swami/Smurf). It doesn't natively support Mac OS X (yet?) and
probably will never support Mac OS classic. wxWin seems to kick ass in
this regard. I'm currently really liking the Glib/GObject/GTK+ layer
effect. All my non GUI stuff is written using GObject so its GUI
independent and I can do OO programming and stick with C (C++ has scared
me away a little, although I can understand the advantages). Cheers.
Josh Green
but personally
i find it much more desirable that the plugin provides
effectively a widget which can be added to a container (provided by the
host) rather than the plugin creating its own window. its just much
neater..
this makes no difference to the problem. whether the plugin creates a
widget or a window, the integration of the event loop is still a
central blocking problem.
I thought
Gtk(mm) is a more natural choice, since it is freely available
on all platforms, voila.
many Qt users feel otherwise. and wxWin is available too, along with
several other kits.
--p
6:25 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh Green wrote:
Please enlighten me, what was the problem then with
multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event loop. Only one toolkit can receive the events
and the others just sit there. Some tollkits can be made to play nicly
(eg. GTK1.2 IIRC), but not all, and maybe not in a standard way.
- Steve
21 Oct
21 Oct
2:27 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On 19 Oct 2002 09:22:13 +0100, Steve Harris wrote:
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh Green
wrote:
does anything speak against opening a second socket and connecting to X
(so X Server sees two clients) then knowing the ID of the X window the
plugin
window could be swallowed into the host.
use threads for the different gui mainloops.
Please enlighten me, what was the problem then
with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event loop. Only one toolkit can receive the events
and the others just sit there. Some tollkits can be made to play nicly
(eg. GTK1.2 IIRC), but not all, and maybe not in a standard way.
2:58 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On 19 Oct 2002 09:22:13 +0100, Steve Harris wrote:
look, there are ways to do this, but they are a mess. people have
managed to integrate GTK+ widgets into Qt programs with a design like
this, but if you read the white paper on this (sorry, no URL handy)
the code is full of hack after kludge after hack to deal with nasty
situations that arise. i read the paper full of optimism and came away
feeling like i had to wash my hands.
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh
Green wrote:
does anything speak against opening a second socket and connecting to X
(so X Server sees two clients) then knowing the ID of the X window the Please enlighten me, what was the problem then
with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event loop. Only one toolkit can receive the events
and the others just sit there. Some tollkits can be made to play nicly
(eg. GTK1.2 IIRC), but not all, and maybe not in a standard way. plugin window could be swallowed into the host.
you'd have to have some way of querying the plugin to know *which*
event loop it needed ("are you a
GTK[1|2]/Qt[1|2|3]/FLTK/XForm/Motif/... plugin?"). which event loops
will you support? what if the plugin wants a different one?
basically, none of the existing toolkits save GTK+ (which is making
moves in this direction but isn't there yet) are written to be used in
situations in which they are not the "first receiver" of X
events. they just don't have the code structure to support:
while (1) {
ev = XGetNextEvent();
loop = find_event_loop_by_window (ev->window);
loop->dispatch (ev);
}
this kind of thing totally messes up their multiplexing of timeouts,
other file descriptor I/O etc. into their central event loop.
you could consider a design on their part. or not. whatever you think
of it, its what we've got for all of them.
--p
2:27 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On 19 Oct 2002 09:22:13 +0100, Steve Harris wrote:
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh Green
wrote:
does anything speak against opening a second socket and connecting to X
(so X Server sees two clients) then knowing the ID of the X window the
plugin
window could be swallowed into the host.
use threads for the different gui mainloops.
Please enlighten me, what was the problem then
with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event loop. Only one toolkit can receive the events
and the others just sit there. Some tollkits can be made to play nicly
(eg. GTK1.2 IIRC), but not all, and maybe not in a standard way.
18 Oct
18 Oct
5:30 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Thu, 2002-10-17 at 22:00, Paul Davis wrote:
thus guaranteeing that no instruments can be written
in other
languages. for all the mistakes the GTK+ crew made, their design to
use C as the base language so as to allow for other languages to
provide "wrappers" was a far-sighted and wise choice. OTOH, i will
concede that the real-time nature of most synthesis would tend to rule
out most of the languages of interest.
I'd like to pick all your brains on this one in particular.
indeed, for a plugin soft-synth, it would only ever make sense to write
it in c/c++ or assembler really, a question of speed. Are there really
people who seriously want to write a synth in aynthing else?
And i don't see how enforcing C++ is an issue: it doesnt force you into
a particular style of programming: you can just as easily write c-like
code in c++, but not the other way round.
Basically, your instrument would be a c++ class, but whatever you do
_inside_ that class is up to you.. no need to use objects inside that.
And basically it just cleans up all the code. I'm really having trouble
seeing the drawbacks (other than one needs a c++ compiler installed, and
the fact that c++ projects take longer to compile). oh, and the c++
class could always include (link to) an assembler version of your code..
The other plugin environemnts are using c++, and i feel that a similar
approach is definitely advantageous when people from other platforms may
consider writing/porting to a linux compatible plugin standard.
-Nick
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
9:52 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Thu, 2002-10-17 at 22:00, Paul Davis wrote:
> thus guaranteeing that no instruments can be written in other
> languages. for all the mistakes the GTK+ crew made, their design to
> use C as the base language so as to allow for other languages to
> provide "wrappers" was a far-sighted and wise choice. OTOH, i will
> concede that the real-time nature of most synthesis would tend to rule
> out most of the languages of interest.
nick <nixx(a)nixx.org.uk> writes:
Basically, your instrument would be a c++ class, but
whatever you do
_inside_ that class is up to you.. no need to use objects inside that.
And basically it just cleans up all the code. I'm really having trouble
seeing the drawbacks (other than one needs a c++ compiler installed, and
the fact that c++ projects take longer to compile). oh, and the c++
class could always include (link to) an assembler version of your code..
The main drawback to using C++ subroutine linkage in today's Linux
environment is the unstable ABI. This has caused many problems when
trying to call binary libraries built using different compilers or
sometimes even different compiler options. Exception handling is a
particularly thorny issue.
The result is a debugging nightmare. Using incompatibly compiled C++
libraries may cause random SEGV's, which are often very hard to debug.
The compilers don't seem to leave enough information in the binaries
they produce for maintainers to determine exactly what ABI options
were used.
The Ardour project struggled so much with this problem that Paul Davis
eventually decided to distribute (almost) all the C++ libraries he
uses in source, statically linking them to ensure that they are always
compiled identically. This draconian solution was not adopted for
casual reasons.
Please note that these problems are deadly to any proposal for a
standard plugin interface.
We can all hope that ABI instabilities will eventually become a thing
of the past, perhaps once GCC version 3 becomes widely adopted. But,
there is no proof that this will happen. Right now, the Linux world
is full of incompatible C++ compiler implementations.
Regards,
--
Jack O'Quin
Austin, Texas, USA
19 Oct
19 Oct
7:49 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Sat, 2002-10-19 at 00:49, Jack O'Quin wrote:
The main drawback to using C++ subroutine linkage in
today's Linux
environment is the unstable ABI. This has caused many problems when
trying to call binary libraries built using different compilers or
sometimes even different compiler options. Exception handling is a
particularly thorny issue.
Please note that these problems are deadly to any proposal for a
standard plugin interface.
We can all hope that ABI instabilities will eventually become a thing
of the past, perhaps once GCC version 3 becomes widely adopted. But,
there is no proof that this will happen. Right now, the Linux world
is full of incompatible C++ compiler implementations.
Yes, this is the main problem, and I am aware of it (its bitten me
enough times..), must have slipped my mind before..
But I guess i'm living in the hope that gcc will settle on a stable ABI
in the not too distant future. I really dont understand why this hasnt
happened a lot earlier (although im no compiler guru) - its really vital
to building a successful platform i would have thought. This is the only
plus windows/macos etc have on their side..
are different versions of gcc3 ABI - compatible?
cheers
-nick
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
21 Oct
21 Oct
1:22 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Sat, Oct 19, 2002 at 10:53:56AM +0100, nick wrote:
are different versions of gcc3 ABI - compatible?
No. I believe 3.0 and 3.1 used the same ABI, but 3.2 changed the ABI again.
All of the ABI changes were to bring it in line with some standard (no idea
what.) 3.2 was a bug fix, but apparently (assuming there aren't any more
bugs) the ABI should be compliant with The Standard now, and hence stable.
Bob
19 Oct
19 Oct
6:28 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Fri, Oct 18, 2002 at 08:34:20 +0100, nick wrote:
indeed, for a plugin soft-synth, it would only ever
make sense to write
it in c/c++ or assembler really, a question of speed. Are there really
people who seriously want to write a synth in aynthing else?
Of course, plenty of MacOS audio software is written in Max/MSP (a
relative of pd). There is also some Windows software written in Sync -
both are graphical languages.
- Steve
1:46 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
Steve Harris wrote:
On Fri, Oct 18, 2002 at 08:34:20 +0100, nick wrote:
Although all the actual DSP objects themselves in MSP are written in C,
just like
in pd and jMax. I don't know about Sync (don't know much about it), but
I suspect
that to also be the case there as well. The point is that all the
actual number
crunching code is in fact written in C, even if you use a very
high-level object-oriented
graphical language like Max/MSP to build the app.
OTOH, CLM is written in Lisp, (hence the name), and some modern Lisps
(i.e. CMUCL)
claim to be as fast as C for floats. So I suppose you could write DSP
code in Lisp if you
really wanted to.
-dgm
indeed, for a plugin soft-synth, it would only
ever make sense to write
it in c/c++ or assembler really, a question of speed. Are there really
people who seriously want to write a synth in aynthing else?
Of course, plenty of MacOS audio software is written in Max/MSP (a
relative of pd). There is also some Windows software written in Sync -
both are graphical languages.
- Steve
3:52 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Sat, Oct 19, 2002 at 11:55:09 -0400, David Gerard Matthews wrote:
While its true that msp objects are written in C they are not all
high level. Sync is a compiler, it may well generate C as an intermediary
langauge, I dont know.
- Steve
Of course,
plenty of MacOS audio software is written in Max/MSP (a
relative of pd). There is also some Windows software written in Sync -
both are graphical languages.
Although all the actual DSP objects themselves in MSP are written in C,
just like
in pd and jMax. I don't know about Sync (don't know much about it), but
I suspect
that to also be the case there as well. The point is that all the
actual number
crunching code is in fact written in C, even if you use a very
high-level object-oriented 
17 Oct
17 Oct
7:58 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Thursday 17 Oct 2002 21:49, nick wrote:
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real "instrument" or "synth" plugin API. but since
my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
along the way)
Although in light of Tommi's post (mastajuuri) i have to reconsider
working on my API. My only problem with mastajuuri is its dependance on
QT (if im not mistaken), sorry.
If people would like to my work-in-progress, i could definitely use some
feedback ;-)
This discussion is open!
-Nick
Mmm, I'm a bit of a TiMidity++ fan, in case anyone's forgotten... so...
I'd want a soft-synth to track MIDI Time Codes or something on each synth
channel so it could sync to an external source, as well as being in sync with
itself internally.
I'd want to be able to generate trigger events locally - I also want to be
able to generate events remotely. I'd prefer MIDI for this (as I've just
bought a MIDI controller keyboard ;-) ).
I'd expect the system to be componentised so there would be event source plug
ins, user interface plug ins, audio sink plug ins, data (sample) source plug
ins. Plus the scheduling engine.
I think that's the basic tool set that I'd be looking for. :-)
Applications should then just be a matter of picking the plugins and gluing
them together...
(And keep the latency introduced by the engine to zero...)
Ta.
-- Peter
18 Oct
18 Oct
6:29 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Thu, Oct 17, 2002 at 09:49:53 +0100, nick wrote:
No, there is no real "instrument" or
"synth" plugin API. but since my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
Hmmm... My experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something up, but it did not look encouraging. I will revisit this
and also try gcc3, which has much better c++ support IIRC.
- Steve
12:05 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
Steve Harris wrote:
Hmmm... My experiments with c++, dsp code and gcc
(recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something up, but it did not look encouraging. I will revisit this
and also try gcc3, which has much better c++ support IIRC.
from my experience the contrary is true. last time i checked the
assembly code produced by -O3 i found nothing to object to. that
was g++ 2.95 compiling drawing routines on rgb buffers (just ints,
no floats, but comparable to audio dsp in a way).
i admit i designed the code around what i expected the optimizer
to do to it, so yes, maybe you need a little experience to get it
right.
tim
12:28 p.m.
New subject: [linux-audio-dev] soft synth as a plugin
On Fri, Oct 18, 2002 at 01:39:13 +0200, Tim Goetze wrote:
I was trying with float, lowpass filters, written in an OO style (so I
expected c++ to be faster).
The assembler output from c++ was obvously inefficient, and I
checked all the inlinging was taking place. The equivalent c was much
better.
- Steve
Hmmm... My
experiments with c++, dsp code and gcc (recent 2.96) did not
turn out very well. For some reason the optimiser totaly chokes on c++
code. I only tried one routine, and I'm no c++ expert, so its possible I
screwed something up, but it did not look encouraging. I will revisit this
and also try gcc3, which has much better c++ support IIRC.
from my experience the contrary is true. last time i checked the
assembly code produced by -O3 i found nothing to object to. that
was g++ 2.95 compiling drawing routines on rgb buffers (just ints,
no floats, but comparable to audio dsp in a way). 
28 Oct
28 Oct
11:45 a.m.
New subject: [linux-audio-dev] soft synth as a plugin
Hi.
On 17 Oct 2002, nick wrote:
Hi
IMO running each synth in its own thread with many synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
No, there is no real "instrument" or "synth" plugin API. but since
my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
along the way)
Although in light of Tommi's post (mastajuuri) i have to reconsider
working on my API. My only problem with mastajuuri is its dependance on
QT (if im not mistaken), sorry.
You are not mistaken. I could change the structure of Mustajuuri to make
some kind of core system (just DSP engine) with no Qt dependencies *IF* it
did get more developers for Mustajuuri (enough to justify dropping all the
Qt's tools (and I do mean tools besides the graphical stuff: Unicode
strings, XML, directory management, date and time services, language
translations etc.)).
But unless there is clear promise of this there is little point in going
for the extra effort.
Mustajuuri is modular in a sense that you can run DSP without
running a GUI. Or you can build alternate GUIs with other toolkits. Then
again there is prabably little point in making the Mustajuuri GUI with
anything but Qt, since the Qt will be necessary anyhow. Since all Linux
vendors distribute (and usually install) Qt it is a fairly safe library to
build on.
Tommi Ilmonen Researcher
Linux/IRIX
audio: Mustajuuri
3D audio/animation: DIVA
8090
days inactive
8101
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
13 participants
participants (13)
-
Bob Ham -
David Gerard Matthews -
Jack O'Quin -
Josh Green -
nick -
nikodimka -
Paul Davis -
Paul Davis -
Peter L Jones -
Steve Harris -
Tim Goetze -
Tommi Ilmonen -
torben hohn