6 Mar
2003
6 Mar
'03
3:35 p.m.
I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers, so it can be used both as
synth and as effect processor. Modular tasks separation allow to extend
possibilities in simple way. Modules can be connected between each other via
channels.
Features:
Audio Input/Output:
- OSS
- JACK
MIDI Input/Output:
- OSS
- ALSA
Plugin's compatability:
- native modules
- LADSPA
This is first pre-beta release. It is a big subject for changes and improvements,
so please send your wishes and bugreports.
Roman
-------------------------------------------
-------- mailto: wormpost(a)mail.ru ---------
-------------------------------------------
18 Mar
18 Mar
10:10 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
Roman Kaljakin wrote:
I am pleased to announce Octavian - a realtime software
synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers,(...)
Well, here we have another modular synth framework. :-)
Hi Roman, i realy like parts of your ui design. just looked at the
screenshots so far, but i think i will try octavian soon.
I would have reacted earlier to your announce, but i was somewhat busy
and didn't follow lad traffic very regulary.
Sseems we have a little problem.
Ok, maybe problem is not exactly the right term, let's put it this way:
Right now, there is beast, there is gAlan, there is ams, and of course
there is also pd, jmax, etc. and lately Octavian, and, rats, there maybe
a zillion of other apps out there that i do not yet know of (authors of
such apps, please append your project to my list:-) )
While each of this projects may have unique approaches to certain
problems, or use different metaphors for similar things, i guess it is a
valid assumption, that they all have _very_ similar goals in terms of
functionality. At least that was my impression after talking with Stefan
(beast) and Torben (gAlan).
The Big Question(tm):
How can we avoid redundant work?
My (somewhat utopious) suggestion:
maybe we should think in components that use/modify a common
datastructure/model.
This has almost (but not completly) nothing to do with merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
12:06 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
The Big Question(tm):
How can we avoid redundant work?
My (somewhat utopious) suggestion:
maybe we should think in components that use/modify
a common
datastructure/model.
I like the sound of that. There shouldn't be any code
that we share. Because we all have different styles,
goals, languages and even licenses. An open standard
would be better as it includes the commercial software
developers among us (like me).
I think the bulk of redundant work is on standard
effects or modules. We don't want to define anything
as to how the modules work with each other, but maybe
draft some sort of a file that compliant programs
either a) convert to code and integrate into the app
at compile-time or b) can open as "modules" if it's a
modular synth.
For example, it's hard to design a filter. At least I
think so. So someone else designs one and releases it
under _whatever_ license they want. If the license
fits your app, you can use some sort of tool that will
convert this file format to code in your language of
choice and insert in the right place automatically.
Whether or not your app fits the correct license, you
can also allow your app to open these files.
I also already devised an xml-based format for modular
synth patches. It needs some work if it's to be an
open standard. It containts a lot of elements that
only make sense w/ my app (i.e., it expects features
that my app has that, to my knowlege, no other app has
yet). But, like I said, I think the most redundant
work is for stuff like filters, oscillators and so
forth. I probably won't benefit too much from this as
my app isn't open source (i'm releasing the midi
implementation in it, however, as an lGPL lib) unless
people release some files under BSD ;)
maybe i'll release some stuff from the app, but not
the app itself as open source.... hmmm...
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
12:20 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
I think the bulk of redundant work is on standard
effects or modules. We don't want to define anything
as to how the modules work with each other, but maybe
draft some sort of a file that compliant programs
either a) convert to code and integrate into the app
at compile-time or b) can open as "modules" if it's a
modular synth.
For example, it's hard to design a filter. At least I
think so. So someone else designs one and releases it
under _whatever_ license they want. If the license
fits your app, you can use some sort of tool that will
convert this file format to code in your language of
LADSPA: its not great for "instruments", but IMHO works at precisely
the correct level for synth modules.
however, all (or nearly all) of the tools mentioned already support
LADSPA and yet it doesn't seem to have done much to to reduce the
redundant work that is going on on these applications.
i think kai's observations in the past about how open source works in
this kind of situation are completely on the mark. it looks
inefficient, and it probably is, but its the way it works and if it
didn't, open source probably wouldn't work either.
--p
1:04 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003 11:15:04 -0500, Paul Davis wrote
I agree with this - I program free software to try and find out how stuff
works, that's the fun for me. If I start to get concerned with things like
code reuse and effeciency of time used, it starts to feel like, well - being
at work ;)
dave
I think the
bulk of redundant work is on standard
effects or modules. We don't want to define anything
as to how the modules work with each other, but maybe
draft some sort of a file that compliant programs
either a) convert to code and integrate into the app
at compile-time or b) can open as "modules" if it's a
modular synth.
For example, it's hard to design a filter. At least I
think so. So someone else designs one and releases it
under _whatever_ license they want. If the license
fits your app, you can use some sort of tool that will
convert this file format to code in your language of
LADSPA: its not great for "instruments", but IMHO works at precisely
the correct level for synth modules.
however, all (or nearly all) of the tools mentioned already support
LADSPA and yet it doesn't seem to have done much to to reduce the
redundant work that is going on on these applications.
i think kai's observations in the past about how open source works in
this kind of situation are completely on the mark. it looks
inefficient, and it probably is, but its the way it works and if it
didn't, open source probably wouldn't work either.
3:26 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
>LADSPA: its not great for "instruments", but IMHO works at precisely
>the correct level for synth modules.
>
Agreed. Well, ok there are some issues, but no real problems. Actualy i
would like arbitrary datatypes. And it would sure be nice to have more
information on the semantics of the ports. The latter one maybe rather a
problem of the hosts not completly implementing everything that is
supported by ladspa (until recently, i didn't know about this rdf
thingy, for instance.)
>
>however, all (or nearly all) of the tools mentioned already support
>LADSPA and yet it doesn't seem to have done much to to reduce the
>redundant work that is going on on these applications.
>
Which i think is related to the above. I think we should first improve
the hosts, so that they actualy use 105% of what is there already,
before we start thinking about a new plugin api. And if i was to start
with som mod. synth. project from scratch, i also would try to keep the
amount of "native modules" as low as possible, since A) no other app can
use them, and B) i would have
to code them myself, while there ladspa plugins exist for almost any job
(including things like making coffee, i'm sure.
Does your microwave oven support LADSPA? :-))
On the other hand, i think it's not realy the question what api we use
for modules. (well, a common api wouldn't hurt ;-) )
As i said, i think the real difficult problem would be defining that
comon model. Maybe what jack does is closer to it.
I agree with this - I program free software to try and
find out how stuff
works, that's the fun for me. If I start to get concerned with things like
code reuse and effeciency of time used, it starts to feel like, well - being
at work ;)
Lol. :-)
Well ok, you might be right, from the POV of a developer, i think this
is exactly the point: we tend to push our own stuff because it's fun, or
maybe selffullfillment (is this the right spelling?). We also tend to be
not that aware of similar work beeing done somewhere else, at least
that's my impression. Or even worse, we _are_ aware of another project,
but hate it :-)
There is much emotional nonsense in those endless flame wars about vim
vs emacs, kde vs gnome, etc.
And the other point you mention is true aswell. It is hard work. And it
usualy includes compromises and all this bitter stuff :-)
But from the users point of view, things look different. Just look at
this kde<->gnome situation. I'm seeing myself as a rather a user than a
developer when it comes to desktop envirements, and i definitly would
like a _realy_ integrated desktop. I don't know much about the issues
they have there, nore do i care that much.
And if you think of it, the situation with all those modular synth apps
is indeed similar in many aspects. We have Jack and Ladspa etc, and
that's great, but i think it's not enough.
Sorry for long post,
Lukas
3:44 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
problem of the hosts not completly implementing
everything that is
supported by ladspa (until recently, i didn't know about this rdf
thingy, for instance.)
that isn't actually part of LADSPA. its an example of the extreme ease
of adding wrappers and new layers to LADSPA precisely because it
represents the lowest common denominator for an audio plugin API.
On the other hand, i think it's not realy the
question what api we use
for modules. (well, a common api wouldn't hurt ;-) )
As i said, i think the real difficult problem would be defining that
comon model. Maybe what jack does is closer to it.
there actually isn't really any commonality between what, say, pd
versus beast do. or between jMax and gAlan. the similarity exists only
on an abstract conceptual plane, which is where algorithms
live. however software isn't abstract - its always instantiated. the
problem here, i think, is that we look at different systems, note
their abstract conceptual similarities and wonder why they need to
both exist when they appear so similar. yet they are not similar as
software, only as ideas. and its the software that is being worked on
- the ideas were worked out years ago - and its the software that is
where the fun is.
But from the users point of view, things look
different. Just look at
this kde<->gnome situation. I'm seeing myself as a rather a user than a
developer when it comes to desktop envirements, and i definitly would
like a _realy_ integrated desktop. I don't know much about the issues
they have there, nore do i care that much.
i've said many times before: i don't believe that "the desktop" is
something that developers of "music" apps should concern themselves
with. "the desktop" is neither the source nor sink for almost any of
the data that we manipulate, and the UI/HCI abstractions and models
that we use are often very different (for good reasons) from those
used by apps that deal primarily with data lacking any temporal
dimension.
i think we should focus on writing good applications that are
independent of what a "desktop" does.
And if you think of it, the situation with all those
modular synth apps
the situation is no different to the one in the h/w world. i don't
hear anyone suggesting that doepfer should quit because moog is making
modular stuff again, or even that they should work together. there are
probably at least a half-dozen companies doing this today - should
they all sit down and work out how to make their stuff interoperable
beyond a 12V/octave standard?
4:13 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
i've said many times before: i don't believe
that "the desktop" is
something that developers of "music" apps should concern themselves
with. [...]
i think we should focus on writing good applications that are
independent of what a "desktop" does.
Yes. It is more useful to think of real time CHI (computer human
interaction) and not real time CHI.
I play my keyboard and the computer makes a sound. This is real time
CHI.
My video monitor displays level meters for the audio interface hardware.
This is real time CHI.
I change the settings on my synthesis program so that the keyboard
causes different sounds in performance. This might be not real time CHI.
In general, you will find that the more you move into real time CHI, the
more robust your audio synthesis/production system will be.
--
(jfm3 2838 BCBA 93BA 3058 ED95 A42C 37DB 66D1 B43C 9FD0)
4:52 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
that isn't actually part of LADSPA.
Ah ok, i mixed that up. sorry.
there actually isn't really any commonality between
what, say, pd
versus beast do. or between jMax and gAlan. the similarity exists only
on an abstract conceptual plane, which is where algorithms
live. however software isn't abstract - its always instantiated. the
problem here, i think, is that we look at different systems, note
their abstract conceptual similarities and wonder why they need to
both exist when they appear so similar. yet they are not similar as
software, only as ideas. and its the software that is being worked on
- the ideas were worked out years ago - and its the software that is
where the fun is.
Hmm...good point.
i've said many times before: i don't believe
that "the desktop" is
something that developers of "music" apps should concern themselves
with.
another good point. That's why i said i don't care. :-)
It was ment as an example. see below again.
And if you
think of it, the situation with all those modular synth apps
the situation is no different to the one in the h/w world.
i don't
hear anyone suggesting that doepfer should quit because moog is making
modular stuff again, or even that they should work together.
Just for the records, i never would be so bold to suggest anyone to quit.
Actualy i would be the first to quit if i felt that what i am trying to
achieve has already been achieved.
Thats part of the reason why i am asking this. There just has to be a
way of making sure that what i am doing does make any sense at all. The
last weeks, there were discussions about redesigning ams from scratch,
and how to do this. But it seems so pointless sometimes, to spend night
after night, thinking about problems that have already been solved
nicely in some other project.
Man, i hate this. every time i try to give smart answers to your posts
on some list, i run out of arguments. :-)))
Guess i better stop now and think it all over.
Kind Regards,
Lukas
19 Mar
19 Mar
2:41 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003 21:37:00 +0100
Lukas Degener <AFBLukas(a)gmx.de> wrote:
actualy there is a difference. we don't have to be afraid of each other,
since we don't have to compete for market shares.
Oh well... forget it.
Well, each synth has it's own goals and design (UI design is significant too),
so defining any common scheme that synths must use will make them a twins for
each other. But I think that some compatibility must exist. As the LADSPA is
common API for filters and FXes (and it is supported by many of existing
synthesizers), maybe it's time for designing a similar API for softsynth
only, that would have abilities of using such features as "voltage
controlling", polyphony, etc.
Roman.
that isn't actually part of LADSPA.
Ah ok, i mixed that up. sorry.
there actually isn't really any commonality
between what, say, pd
versus beast do. or between jMax and gAlan. the similarity exists only
on an abstract conceptual plane, which is where algorithms
live. however software isn't abstract - its always instantiated. the
problem here, i think, is that we look at different systems, note
their abstract conceptual similarities and wonder why they need to
both exist when they appear so similar. yet they are not similar as
software, only as ideas. and its the software that is being worked on
- the ideas were worked out years ago - and its the software that is
where the fun is.
Hmm...good point.
i've said many times before: i don't
believe that "the desktop" is
something that developers of "music" apps should concern themselves
with.
another good point. That's why i said i don't care. :-)
It was ment as an example. see below again.
And if you
think of it, the situation with all those modular synth apps
the situation is no different to the one in the h/w world.
i don't
hear anyone suggesting that doepfer should quit because moog is making
modular stuff again, or even that they should work together.
Just for the records, i never would be so bold to suggest anyone to quit.
Actualy i would be the first to quit if i felt that what i am trying to
achieve has already been achieved.
Thats part of the reason why i am asking this. There just has to be a
way of making sure that what i am doing does make any sense at all. The
last weeks, there were discussions about redesigning ams from scratch,
and how to do this. But it seems so pointless sometimes, to spend night
after night, thinking about problems that have already been solved
nicely in some other project.
Man, i hate this. every time i try to give smart answers to your posts
on some list, i run out of arguments. :-)))
Guess i better stop now and think it all over.
Kind Regards,
Lukas
7:16 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
Lukas Degener wrote:
Guess i better stop now and think it all over.
Kind Regards,
Lukas
Yeah, i like replying to my own mails :-)
Ok, now i thought it over somewhat, and hmmm....
i hate to say that, but i think, hmmm.... ok, you are right, Paul.
maybe. kindof. a little bit. :)
We realy shouldn't try to enforce different projects to essentialy look
and feel (and finaly do) the same.
This would not be the point.
I'm not sure anymore what i actualy ment to suggest. So i will just shut
up for now until i can come up with something more concrete.
Regards,
Lukas
18 Mar
18 Mar
5:23 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 02:38:49 -0500, Paul Davis wrote:
Hey, the broken-record technique works ;)
I believe that its possible to use RDF to express all the annotations
neccesary to make complex (DSP) modules from LADSPA. The UI issue is
unsolved though.
Er, actually several of the compaines make hardware that is interoperable,
including Doepfer. You can plug AS modules into a Doepfer frame for
example.
In ultra pedantic mode its generally 1v / octave. Historically there was
also 1.2, but its pretty mcuh died out.
- Steve
problem of the
hosts not completly implementing everything that is
supported by ladspa (until recently, i didn't know about this rdf
thingy, for instance.)
that isn't actually part of LADSPA. its an example of the extreme ease
of adding wrappers and new layers to LADSPA precisely because it
represents the lowest common denominator for an audio plugin API. And if you
think of it, the situation with all those modular synth apps
the situation is no different to the one in the h/w world. i don't
hear anyone suggesting that doepfer should quit because moog is making
modular stuff again, or even that they should work together. there are
probably at least a half-dozen companies doing this today - should
they all sit down and work out how to make their stuff interoperable
beyond a 12V/octave standard?
5:51 p.m.
New subject: [linux-audio-dev] Interface with real modules
Er, actually several of the compaines make hardware
that is interoperable,
including Doepfer. You can plug AS modules into a
Doepfer frame for
example.
Has anyone tried making a synth app that works w/ real
modular synths? I'm too poor to afford these things
(kinda what got me into audio development), but I do
have a paia fatman I've been playing w/.. I've managed
to use the voltage outs from it to control my synth,
but I know the FatMan isn't the standard volrage
levels you see in the likes of Doepfer, AS,
synthesizers.com, etc.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
19 Mar
19 Mar
6:03 a.m.
New subject: [linux-audio-dev] Interface with real modules
On Tue, 18 Mar 2003, Thomas Webb wrote:
Has anyone tried making a synth app that works w/
real
modular synths? I'm too poor to afford these things
(kinda what got me into audio development), but I do
have a paia fatman I've been playing w/.. I've managed
to use the voltage outs from it to control my synth,
but I know the FatMan isn't the standard volrage
levels you see in the likes of Doepfer, AS,
synthesizers.com, etc.
I have connected my AlsaModularSynth with a Doepfer synth. It is no
problem at all to route signals between them via the soundcard as long as
the frequency is in the audio range. With my SB Live I could even use LFO
signals down to less than 1 Hz without too much distortion of the LFO
waveform. But the general feature of soundcards to block DC voltages
will make the I/O of envelopes and constant CVs impossible.
However you can still have a lot of fun e.g. having FM or Ringmod between
software and true analogue VCOs. It would also be a very good idea to
combine a true analogue VCF with a digital synth as it's the filter that
is the weakest point of digital synthesis. It is then however difficult to
implement proper VCF tracking. This could only be done by using a true
analogue MIDI to CV converter, let this control the VCF tracking and send
the same notes to the softsynth and the true analogue MCV connected to the
VCF.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
10 a.m.
New subject: [linux-audio-dev] Interface with real modules
However you can still have a lot of fun e.g. having
FM or Ringmod between
software and true analogue VCOs. It would also be a
very good idea to
combine a true analogue VCF with a digital synth as
it's the filter that
is the weakest point of digital synthesis. It is
then however difficult to
implement proper VCF tracking. This could only be
done by using a true
analogue MIDI to CV converter, let this control the
VCF tracking and send
the same notes to the softsynth and the true
analogue MCV connected to the
VCF.
yeah, the main thing I was thinking of was using an
analogue filter.. The medical company I work for has
this real hightech voltmeter (high res and
everything). I can probably get that to work
perfectly with any modules. The only problem is it's
freaky expensive. Too bad a standard soundcard won't
work quite right.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
20 Mar
20 Mar
5:55 a.m.
New subject: [linux-audio-dev] Interface with real modules
Thomas Webb wrote:
yeah, the main thing I was thinking of was using an
analogue filter.. The medical company I work for has
this real hightech voltmeter (high res and
everything). I can probably get that to work
perfectly with any modules. The only problem is it's
freaky expensive. Too bad a standard soundcard won't
work quite right.
So actualy we would need a CV to MIDI (or similar) converter, that is
cheaper than those hightech voltmeter, Thomas mentions.
With all the "real" module systems (Moog, Doepfer, and friends) existing
for so long now, i wonder if those companies haven't already thought
about a solution for this particular problem. Or is it just "techincaly"
difficult?
Lukas
11:10 a.m.
New subject: [linux-audio-dev] Interface with real modules
On Thu, Mar 20, 2003 at 10:40:19AM +0100, Lukas Degener wrote:
Thomas Webb wrote:
http://directory.google.com/Top/Arts/Music/Instruments/Electronic/Synthesiz…
found this with only a little digging:
http://www.doepfer.de/a192.htm
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's SWIRLY TURQUOISE CAPTAIN!
(random hero from isometric.spaceninja.com)
yeah, the main thing I was thinking of was using
an
analogue filter.. The medical company I work for has
this real hightech voltmeter (high res and
everything). I can probably get that to work
perfectly with any modules. The only problem is it's
freaky expensive. Too bad a standard soundcard won't
work quite right.
So actualy we would need a CV to MIDI (or similar) converter, that is
cheaper than those hightech voltmeter, Thomas mentions.
11:55 a.m.
New subject: [linux-audio-dev] Interface with real modules
So actualy we would need a CV to MIDI (or similar)
converter, that is
cheaper than those hightech voltmeter, Thomas
mentions.
I already thought about a CV to MIDI converter, but
that doesn't quite do everything that directly
interfacing with the voltage does. For one, I won't be
able to patch things like you do w/ a modular. CV to
MIDI also doesn't quite work right when you are
dealing with pitch. One of the reasons I wanted to get
this working is because I wanted to control my
softsynth with this thing
http://www.analoguesystems.co.uk/Reviews/fconnection_review.htm
a CV to MIDI won't work (not cleanly, anyway... there
are some crappy workarounds)
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
3:06 p.m.
New subject: [linux-audio-dev] Interface with real modules
From: "Thomas Webb" <magusofthedark(a)yahoo.com>
I already thought about a CV to MIDI converter, but
that doesn't quite do everything that directly
interfacing with the voltage does.
With older soundcards, like ISA SoundBlasters that are
bristling with capacitors and resistors, it's often
easy to find the DC blocking capacitor and bypass it.
There are probably hobby electronics kits around (Maplin
in the UK, Vellemann in Germany?) for making ADCs and DACs
to connect to the parallel port.
Paul.
_____________________________
m a x i m | digital audio
http://mda-vst.com
_____________________________
18 Mar
18 Mar
5:58 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
Hey, the broken-record technique works ;)
it sure does. what would you like me to repeat next ?
probably at
least a half-dozen companies doing this today - should
they all sit down and work out how to make their stuff interoperable
beyond a 12V/octave standard?
Er, actually several of the compaines make hardware that is interoperable,
including Doepfer. You can plug AS modules into a Doepfer frame for
example.
19 Mar
19 Mar
5:30 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 04:53:42 -0500, Paul Davis wrote:
bad analogy on my part. i should have said "should they all sit down
and merge their design efforts so that their stuff all looks the same,
has the same knobs and switches, and uses the same internal circuit
components?" you can, of course, plug any JACK-enabled modsynth into
any other one, but this doesn't really answer the question.
OK, sure. Obviously the reason you whan to do this in the first place is
that the different brands have different qualities.
- Steve
Hey, the
broken-record technique works ;)
it sure does. what would you like me to repeat next ?
probably
at least a half-dozen companies doing this today - should
they all sit down and work out how to make their stuff interoperable
beyond a 12V/octave standard?
Er, actually several of the compaines make hardware that is interoperable,
including Doepfer. You can plug AS modules into a Doepfer frame for
example. 
21 Mar
21 Mar
6:06 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 08:11:33PM +0100, Lukas Degener wrote:
Sorry... i have moved to a new house and am currently building the
kitchen. so expect my answers to this thread next week...
On the other hand, i think it's not realy the
question what api we use
for modules. (well, a common api wouldn't hurt ;-) )
As i said, i think the real difficult problem would be defining that
comon model. Maybe what jack does is closer to it.
The first step we should all take, is read each others code and discuss
it here on the list. during the XAP thread Simon Jenkins improved the
sort code of SpiralSynth for example.
All our code is Open and if you know your editor well you can copy paste
very much...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
I agree with this - I program free software to try
and find out how stuff
works, that's the fun for me. If I start to get concerned with things like
code reuse and effeciency of time used, it starts to feel like, well -
being
at work ;)
Lol. :-)
Well ok, you might be right, from the POV of a developer, i think this
is exactly the point: we tend to push our own stuff because it's fun, or
maybe selffullfillment (is this the right spelling?). We also tend to be
not that aware of similar work beeing done somewhere else, at least
that's my impression. Or even worse, we _are_ aware of another project,
but hate it :-)
18 Mar
18 Mar
2:29 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003, Thomas Webb wrote:
I also already devised an xml-based format for
modular
synth patches. It needs some work if it's to be an
I was very impressed by the XML representation of LADSPA plugins
presented by Steve Harris at the LAD conference last weekend. He writes
the code and parameter specifications of his LADSPA plugins in XML and
then converts ("compiles") them to the C code according to ladspa.h.
What I like about this solution is that it would not only allow to share
modules among the many softsynths, but it could also be used to solve the
GUI/Toolkit problem. Namely one could also express the GUI layout
information in XML. People can then "compile" the XML files and get both
the module's DSP code in the format appropriate for their synth and also
the GUI code for the Toolkit (e.g. QT ot GTK) of their choice.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
2:36 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
I was very impressed by the XML representation of
LADSPA plugins
presented by Steve Harris at the LAD conference last
weekend. He writes
the code and parameter specifications of his LADSPA
plugins in XML and
then converts ("compiles") them to the C code
according to ladspa.h.
Here's an idea: find a way to conver these same XML
files into dsp assembler. All the sudden, the same
stuff you use to make a softsynth can be reused for a
hardware synth!
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
4:03 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
Thomas Webb wrote:
Well, compiling the generated C code with a cross assembler
for the DSP will do that for you :)
The tricky bit would be making the generated C code "agnostic"
enough with regard to issues like:
~floating vs fixed point arithmetic
~block processing vs blockless
~control value representation and rate
~code calling conventions
~the nature of connections between modules
Even ignoring (for a moment) the idea of compiling for a dsp,
modular synth developers would want to make different decisions
from each other regarding some of the above points.
Simon Jenkins
(Bristol, UK)
I was very
impressed by the XML representation of
LADSPA plugins
presented by Steve Harris at the LAD conference last
weekend. He writes
the code and parameter specifications of his LADSPA
plugins in XML and
then converts ("compiles") them to the C code
according to ladspa.h.
Here's an idea: find a way to conver these same XML
files into dsp assembler. All the sudden, the same
stuff you use to make a softsynth can be reused for a
hardware synth!
5:19 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
The tricky bit would be making the generated C code
"agnostic"
enough with regard to issues like:
~floating vs fixed point arithmetic
~block processing vs blockless
~control value representation and rate
~code calling conventions
~the nature of connections between modules
Even ignoring (for a moment) the idea of compiling
for a dsp,
modular synth developers would want to make
different decisions
from each other regarding some of the above points.
Well, you'd also want to make this all language
agnostic as well. just provide an open _standard_ for
how the generated code is supposed to work and how the
xml files are to be constructed. Then, there can be
different implementations. competing implementations.
What makes open source great is that there are a bunch
of modular synths out there and they are all gonna be
great. Differing implementations allows for the
possibility of there being implementations specialized
for different DSPs.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
5:16 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 10:27:42 -0800, Thomas Webb wrote:
Here's an idea: find a way to conver these same
XML
files into dsp assembler. All the sudden, the same
stuff you use to make a softsynth can be reused for a
hardware synth!
You cant generate "normal" DSP code from C as it tends to be fixedpoint,
and C doesn't support it.
- Steve
5:28 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
You cant generate "normal" DSP code from C
as it
tends to be fixedpoint,
and C doesn't support it.
- Steve
Yeah, fixed point DSPs are cheaper, no? I wasn't
suggesting using a C compiler to generate assembler. I
was thinking more along the lines of making a new
compiler/converter kinda thingy that creates the code
itself from xml files..
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
19 Mar
19 Mar
5:42 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 01:19:37 -0800, Thomas Webb wrote:
I thin you maybe misunderstood the tech here, its just XML with lumps of C
in it, the XML takes care of the tedious pointer mangling that is required
to made a plugin in C: http://plugin.org.uk/ladspa-swh/amp_1181.xml
(view source in Moz, cos it uses the CSS stylsheet to render it by
default).
- Steve
You cant
generate "normal" DSP code from C as it
tends to be fixedpoint,
and C doesn't support it.
- Steve
Yeah, fixed point DSPs are cheaper, no? I wasn't
suggesting using a C compiler to generate assembler. I
was thinking more along the lines of making a new
compiler/converter kinda thingy that creates the code
itself from xml files..
10:06 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
I thin you maybe misunderstood the tech here, its
just XML with lumps of C
in it, the XML takes care of the tedious pointer
mangling that is required
to made a plugin in C:
http://plugin.org.uk/ladspa-swh/amp_1181.xml
(view source in Moz, cos it uses the CSS stylsheet
to render it by
default).
oh, sorry. I just sort of assumed that it used some
sort of generic math stuff, not C code (kinda like
matlab) maybe it should be that way! It'd be a pain in
the ass to implement, which is why I'm probably not
gonna try.
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
2:41 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003 19:20:29 +0100 (CET)
"Dr. Matthias Nagorni" <mana(a)suse.de> wrote:
On Tue, 18 Mar 2003, Thomas Webb wrote:
Yes, I think it would be a logical extension of LADSPA specification.
I also already devised an xml-based format for
modular
synth patches. It needs some work if it's to be an
I was very impressed by the XML representation of LADSPA plugins
presented by Steve Harris at the LAD conference last weekend. He writes
the code and parameter specifications of his LADSPA plugins in XML and
then converts ("compiles") them to the C code according to ladspa.h.
What I like about this solution is that it would not only allow to share
modules among the many softsynths, but it could also be used to solve the
GUI/Toolkit problem. Namely one could also express the GUI layout
information in XML. People can then "compile" the XML files and get both
the module's DSP code in the format appropriate for their synth and also
the GUI code for the Toolkit (e.g. QT ot GTK) of their choice.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
5:37 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 09:32:34 +0300, Roman Kaljakin wrote:
Yes, it would be useful, but its a lot of work (DTD, toolkit bindings
etc.) and it doesn;t solve the immediate problem of UIs that cannot be
succesfully represented in XML, eg. (my favourite exmaple) a lowpass
filter plugin, which should render the freq. response of the filter.
- Steve
What I like
about this solution is that it would not only allow to share
modules among the many softsynths, but it could also be used to solve the
GUI/Toolkit problem. Namely one could also express the GUI layout
information in XML. People can then "compile" the XML files and get both
the module's DSP code in the format appropriate for their synth and also
the GUI code for the Toolkit (e.g. QT ot GTK) of their choice.
Yes, I think it would be a logical extension of LADSPA specification.
7:06 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Wed, 19 Mar 2003, Steve Harris wrote:
etc.) and it doesn;t solve the immediate problem of
UIs that cannot be
succesfully represented in XML, eg. (my favourite exmaple) a lowpass
filter plugin, which should render the freq. response of the filter.
Yes, I'm aware of the problem. Look e.g. at the envelope modules of ams,
the scope and spectrum viewer and the dynamic waves module. They all have
canvas where some more or less complicated graphics is drawn. But wouldn't
it be posssible to express these things with XML as well ? Hope I soon
find the time to work out some sample code...
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
8:24 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 11:57:35 +0100, Dr. Matthias Nagorni wrote:
On Wed, 19 Mar 2003, Steve Harris wrote:
Well, the curve would depend on the character of the filter / compressor /
whatever. I guess you could embedd an expression representing the shape,
but that just seems like hard work.
A more general and untilmatly simpler solution is to allow people to write
code for the UI.
- Steve
etc.) and it doesn;t solve the immediate problem
of UIs that cannot be
succesfully represented in XML, eg. (my favourite exmaple) a lowpass
filter plugin, which should render the freq. response of the filter.
Yes, I'm aware of the problem. Look e.g. at the envelope modules of ams,
the scope and spectrum viewer and the dynamic waves module. They all have
canvas where some more or less complicated graphics is drawn. But wouldn't
it be posssible to express these things with XML as well ? Hope I soon
find the time to work out some sample code...
21 Mar
21 Mar
7:14 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 09:28:42AM +0000, Steve Harris wrote:
On Wed, Mar 19, 2003 at 09:32:34 +0300, Roman Kaljakin
wrote:
Yes, it would be useful, but its a lot of work (DTD, toolkit bindings
etc.) and it doesn;t solve the immediate problem of UIs that cannot be
succesfully represented in XML, eg. (my favourite exmaple) a lowpass
filter plugin, which should render the freq. response of the filter.
have a second instance of the filter on a sheet, send an impulse
through it and sample it using a sampler :) should work.
But the general problem is of course not solved...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
What I
like about this solution is that it would not only allow to share
modules among the many softsynths, but it could also be used to solve the
GUI/Toolkit problem. Namely one could also express the GUI layout
information in XML. People can then "compile" the XML files and get both
the module's DSP code in the format appropriate for their synth and also
the GUI code for the Toolkit (e.g. QT ot GTK) of their choice.
Yes, I think it would be a logical extension of LADSPA specification.
7947
days inactive
7962
days old
linux-audio-dev@lists.linuxaudio.org
34 comments
12 participants
participants (12)
-
Dave Griffiths -
Dr. Matthias Nagorni -
jfm3 -
Lukas Degener -
Paul Davis -
Paul Kellett -
Paul Winkler -
Roman Kaljakin -
Simon Jenkins -
Steve Harris -
Thomas Webb -
torbenh＠gmx.de