On Wed, Mar 19, 2003 at 09:28:42AM +, Steve Harris wrote:
> On Wed, Mar 19, 2003 at 09:32:34 +0300, Roman Kaljakin wrote:
> > > 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/Tool
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
> 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 b
On Wed, Mar 19, 2003 at 11:57:35 +0100, Dr. Matthias Nagorni wrote:
> 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 rende
On Tue, Mar 18, 2003 at 01:19:37 -0800, Thomas Webb wrote:
> > 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
>
On Wed, Mar 19, 2003 at 09:32:34 +0300, Roman Kaljakin wrote:
> > 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
> > informat
On Tue, Mar 18, 2003 at 04:53:42 -0500, Paul Davis wrote:
> >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 in
On Tue, Mar 18, 2003 at 11:41:38 -0500, Ivica Bukvic wrote:
> As you can see OSC is very powerful and already present in a number of
> apps. While LADSPA protocol might be also very useful, it implies that
> the module or synth is presented in a LADSPA plugin form, while OSC can
> also manipulate s
On Tue, 18 Mar 2003 21:37:00 +0100
Lukas Degener <[EMAIL PROTECTED]> wrote:
> >
> >
> >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 exi
On Tue, 18 Mar 2003 19:20:29 +0100 (CET)
"Dr. Matthias Nagorni" <[EMAIL PROTECTED]> wrote:
> 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 representat
> >I'm new to LADSPA, but isn't that what LADSPA control
> >protocol does?
> >
> Dunno. have to do some reading. What is Open Sound Control?
See http://cnmat.cnmat.berkeley.edu/OSC/ for more info.
Basically it is a network protocol that by default uses UDP via LAN to
communicate between various a
Steve Harris writes:
> On Tue, Mar 18, 2003 at 08:35:30 +0100, Lukas Degener wrote:
> > Dunno. have to do some reading. What is Open Sound Control?
>
> Its a synthesis focused message passing protocol. Generally run over UDP.
> Pretty popular in the academic world. It could/should be a canditate f
>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 o
On Tue, Mar 18, 2003 at 08:35:30 +0100, Lukas Degener wrote:
> >
> >
> >I'm new to LADSPA, but isn't that what LADSPA control
> >protocol does?
> >
> Dunno. have to do some reading. What is Open Sound Control?
Its a synthesis focused message passing protocol. Generally run over UDP.
Pretty popula
> 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 t
On Tue, Mar 18, 2003 at 10:25:47 -0800, Thomas Webb wrote:
> I'm new to LADSPA, but isn't that what LADSPA control
> protocol does? I think it would be better if there was
> something like that, but the plugin can work with or
> without the gui.
LCP is mostly hypothetical. There are some sample UI
On Tue, Mar 18, 2003 at 02:38:49 -0500, Paul Davis wrote:
> >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 eas
> 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
>
> Ev
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
>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
r
> 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'
> How about having all apps implement Open Sound
> Control (some of them already have, such as pd,
> csound etc.)?
>
> Then you could control them all from one source
> (i.e. RTMix). Then, suddenly there would be no
> redundancy ;-)...
I'm new to LADSPA, but isn't that what LADSPA control
protoco
ate: 2003/03/18 Tue AM 08:54:55 EST
> To: [EMAIL PROTECTED]
> 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 sys
On Tue, 18 Mar 2003 11:15:04 -0500, Paul Davis wrote
> >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 cod
>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
> 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,
go
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 loo
27 matches
Mail list logo
