>I appreciate when Paul Davis points out that a compressor/limitor
>needing an n-point curve is clearly why I need the array extension. A
>multi-band equalizer with non-fixed bands is also a very good example.
>However, I don't intend to solve the GUI automation issue. For a generic
>represent
>> I certainly agree that envelope control can be implemented by the host
>> passing dynamically changing parameters to the plugin. I have already
>> given a lot of thought on that. Consider the situation of a volume
>> adjustment plugin with host-controlled parameter as the envelope.
>> Suppo
On Sun, 12 May 2002, Likai Liu wrote:
> I certainly agree that envelope control can be implemented by the host
> passing dynamically changing parameters to the plugin. I have already
> given a lot of thought on that. Consider the situation of a volume
> adjustment plugin with host-controlled p
On Sun, 12 May 2002, Likai Liu wrote:
> Richard Guenther wrote:
>
> >Its certainly possible - but the problem with LADSPA is the host-centric
> >buffer management. Though you could add a callback asking for the output
> >buffer size.
> >
> >Richard.
> >
> This should be easy to do as well, but s
Richard Guenther wrote:
>Its certainly possible - but the problem with LADSPA is the host-centric
>buffer management. Though you could add a callback asking for the output
>buffer size.
>
>Richard.
>
This should be easy to do as well, but someone needs to "show the code"
... ;-)
And someone wou
I certainly agree that envelope control can be implemented by the host
passing dynamically changing parameters to the plugin. I have already
given a lot of thought on that. Consider the situation of a volume
adjustment plugin with host-controlled parameter as the envelope.
Suppose each buffer
On Sun, 12 May 2002, Paul Davis wrote:
> >>I'm afraid it would. You need to think about this some more. In any
> >>given unit of time, a certain number of samples are transformed into a
> >>varying air pressure wave. What matters is the relation between those
> >>samples and the original source m
>>I'm afraid it would. You need to think about this some more. In any
>>given unit of time, a certain number of samples are transformed into a
>>varying air pressure wave. What matters is the relation between those
>>samples and the original source material. The number of them remains
>>the same p
>On Sun, 12 May 2002, Kai Vehmanen wrote:
>
>> On Sat, 11 May 2002, Likai Liu wrote:
>>
>> > Please consider my proposal for array extension of the LADSPA:
>>
>> As the one who encouraged to "show the code", I feel obliged to give at
>> least some feedback, but I'm afraid it's not very positive
On Sun, 12 May 2002, Kai Vehmanen wrote:
> On Sat, 11 May 2002, Likai Liu wrote:
>
> > Please consider my proposal for array extension of the LADSPA:
>
> As the one who encouraged to "show the code", I feel obliged to give at
> least some feedback, but I'm afraid it's not very positive this tim
On Sat, 11 May 2002, Likai Liu wrote:
> Please consider my proposal for array extension of the LADSPA:
As the one who encouraged to "show the code", I feel obliged to give at
least some feedback, but I'm afraid it's not very positive this time. The
proposal itself looks fine, but I'm not sure ho
Paul Davis wrote:
>I'm afraid it would. You need to think about this some more. In any
>given unit of time, a certain number of samples are transformed into a
>varying air pressure wave. What matters is the relation between those
>samples and the original source material. The number of them remai
>you mentioned that you have never seen any plugin that outputs a
>different number of samples than inputs. I think the time-stretching
>plugin is a very legitimate example, and I certainly don't understand
>your rationale that a time-stretching plugin should output the same
>number of samples
Please consider my proposal for array extension of the LADSPA:
cut
/* This flag indicates that a port is an array of LADSPA_Data. The size
of the array, which is the number of LADSPA_Data elements in the array,
is stored in the index [-1] of the passing pointer. Further implication
Kai Vehmanen wrote:
>
> The general consensus
> has been (as I've interpreted it) that either convince Richard to adopt
> your change, or create a new plugin standard.
yeah. i want more standards. i think each project should have their own
optimized standard based on LADSPA. embrace and extend.
On Fri, 10 May 2002, Likai Liu wrote:
>> not possible.
>> this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
> sigh, I knew these question would not yield any constructive answer.
> simple is a rather subjective term and that very much depends on
> personal preference. I did r
> you mentioned that you have never seen any plugin that outputs a
> different number of samples than inputs. I think the time-stretching
> plugin is a very legitimate example, and I certainly don't understand
> your rationale that a time-stretching plugin should output the same
> number of sample
Paul Davis wrote:
>>as a completely different issue, is there a way to indicate if a
>>non-audio port is an array (instead of a single value),
>>
>not possible.
>
>this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
>
sigh, I knew these question would not yield any constructi
>as a completely different issue, is there a way to indicate if a
>non-audio port is an array (instead of a single value),
not possible.
this is "ladSpa": Linux Audio Development SIMPLE Plugin Architecture
and is there a
>clean way to
On Fri, 10 May 2002, Likai Liu wrote:
> I suggest$HOME/.ladspa/presets/[plugin-name]/*for user-defined
> presets.
> and all other default presets in
> $PREFIX/share/ladspa/presets/[plugin-name]/*are installed
> read-only, but can be overridden by user-defined presets.
I just wa
I suggest$HOME/.ladspa/presets/[plugin-name]/*for user-defined
presets.
and all other default presets in
$PREFIX/share/ladspa/presets/[plugin-name]/*are installed
read-only, but can be overridden by user-defined presets.
I think classifying the ladspa plugin types in the $PREFIX
>this is even better (and what I was probably hinting at). Presets should be th
>en even deeper under
>$LADSPA_PATH/share/ladspa/presets/[plugin]/
>and $LADSPA_PATH is our $PREFIX
this conflicts with the definition of LADSPA_PATH in ladspa.h
>For the plugins it could be considered to further div
Hi Conrad,
this is even better (and what I was probably hinting at). Presets should be then even
deeper under
$LADSPA_PATH/share/ladspa/presets/[plugin]/
and $LADSPA_PATH is our $PREFIX
For the plugins it could be considered to further divide it into
$LADSPA_PATH/lib/ladspa/
producers/ (no i
On Tue, 7 May 2002, Taybin Rutkin wrote:
> On Tue, 7 May 2002 [EMAIL PROTECTED] wrote:
>
> gchar buf[16];
>
> for (guint i = 0; i < port_count(); i++){
> if (LADSPA_IS_PORT_CONTROL(port_descriptors()[i])){
> child = new XMLNo
On Tue, 7 May 2002 [EMAIL PROTECTED] wrote:
> Idem for presets : this subject has been discussed a lot, but how do we store
> them and where, finally ?
Where? That was never really decided. I think the idea was to have one
under $LADSPA_PATH/presets and that others could be added as well. I
On Tue, May 07, 2002 at 10:38:09 +0200, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I visited recently www.ladspa.org, and I would like to know where the official
> ldp (lasdpa protocol to change values) resides.
If you mean LCP, it was never made "official" but there is some reference
code at htt
Hi all,
I visited recently www.ladspa.org, and I would like to know where the official
ldp (lasdpa protocol to change values) resides.
Besides, I did remember a attempt to recommend the use of normalized to [-1;1]
signals, but I did not see it mentionned anywhere, has there been a decision
On Wed, Apr 10, 2002 at 09:33:35 -0700, [EMAIL PROTECTED] wrote:
> It looks like a LADSPA plugin, by the time it sees the
> data is only seeing a subset of the data -- potentially.
> If that subset of data is the entire portion of the
This isn't a problem, most plugins contain a ringbuffer that h
[This is a long post ...]
I am going to release the latest version of the Gnome
Wave Cleaner in the next couple of days, just waiting
on a test to make sure the configure works on suse-linux.
The project seems to be fairly mature, and now I am
*finally* thinking about making plug-ins for de-nois
Hi, having had many discussion with Steve Harris about LADSPA I decided to
finally contribute something last week, and the result is an XMMS plug-in
that hosts LADSPA plugins. So far it is available only as source, and
relies on ladspa.h and XMMS already being installed.
http://www.ecs.soton.ac.u
On Fri, Apr 05, 2002 at 06:45:59 +0200, Richard Guenther wrote:
> On Thu, Apr 04, 2002 at 11:03:25PM +0100, Steve Harris wrote:
> > On Thu, Apr 04, 2002 at 03:35:59 -0500, Paul Davis wrote:
> > > as at least one of those people, i should note that this occurs only
> > > because i am using the g_mo
On Thu, Apr 04, 2002 at 11:03:25PM +0100, Steve Harris wrote:
> On Thu, Apr 04, 2002 at 03:35:59 -0500, Paul Davis wrote:
> > >At least one person is dlopen-ing LADSPA plugins with RTLD_GLOBAL, and this
> > >can potentially cause problems with plugins that have clashing globals.
> >
> > as at lea
On Thu, Apr 04, 2002 at 03:35:59 -0500, Paul Davis wrote:
> >At least one person is dlopen-ing LADSPA plugins with RTLD_GLOBAL, and this
> >can potentially cause problems with plugins that have clashing globals.
>
> as at least one of those people, i should note that this occurs only
> because i
On Thu, Apr 04, 2002 at 03:35:59 -0500, Paul Davis wrote:
> >At least one person is dlopen-ing LADSPA plugins with RTLD_GLOBAL, and this
> >can potentially cause problems with plugins that have clashing globals.
>
> as at least one of those people, i should note that this occurs only
> because i
>At least one person is dlopen-ing LADSPA plugins with RTLD_GLOBAL, and this
>can potentially cause problems with plugins that have clashing globals.
as at least one of those people, i should note that this occurs only
because i am using the g_module library, which uses RTLD_GLOBAL
implicitly. it
At least one person is dlopen-ing LADSPA plugins with RTLD_GLOBAL, and this
can potentially cause problems with plugins that have clashing globals.
Given that LADSPA plugins shouldn't be exporting global variables to the
rest of the world anyway it would be better if this didn't cause any
problem
Yep, definite consensus. I nearly had time to sort this out last weekend,
but not quite...
--Richard
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Steve
> Harris
> Sent: 18 March 2002 12:32
> To: [EMAIL PROTECTED]
> Subject:
On Mon, Mar 18, 2002 at 09:33:11 +0200, Tommi Ilmonen wrote:
> This is important since a dynamics plugin needs to know what is the
> nominal zero dB amplitude so the signals can be scaled accordingly.
> Personally I prefer 1.0 as being 0 dB (signal range -1.0 to 1.0), but I
> assume LADSPA people
On Sat, Mar 16, 2002 at 08:11:01 +0100, David Olofson wrote:
> On Friday 15 March 2002 13.59, Robert Jonsson wrote:
> > Hi,
> >
> > I think it's not so much XML as custom widgets.
> >
> > Some plugs will probably work better with specialised widgets that
> > is perhaps only applicable to this part
Hi.
Quick question: Is there an expected range for audio signals in the
LADSPA?
I was testing my dynamics plugins with the "applyplugin" -app in the
LADSPA SDK and found out that applyplugin uses the range of 16-bit
integers as the range of audio signal with no scaling. Is this a standard?
Or i
On Saturday 16 March 2002 21.22, Paul Davis wrote:
> >IMHO, a "Plugin GUI Toolkit" should be designed so that
> > specialized GUIs like that wouldn't have to use actual widgets
> > for such things, but rather an "Active Canvas", that lets you do
> > basic drawing as well as mark up "click zones" a
>IMHO, a "Plugin GUI Toolkit" should be designed so that specialized
>GUIs like that wouldn't have to use actual widgets for such things,
>but rather an "Active Canvas", that lets you do basic drawing as well
>as mark up "click zones" and the like.
>
>Perhaps not too different from the internal
On Friday 15 March 2002 13.59, Robert Jonsson wrote:
> Hi,
>
> I think it's not so much XML as custom widgets.
>
> Some plugs will probably work better with specialised widgets that
> is perhaps only applicable to this particular plugin.
IMHO, a "Plugin GUI Toolkit" should be designed so that spe
On Fri, Mar 15, 2002 at 01:10:31 +0100, Stefan Kost wrote:
> > The GUI *is* described in XML, I built it in glade:
>
>
>why do you then say that "...things that really need guis can't be
>easily described in XML..." ?
>
The gui can be easily described in xml (ie. the layout and callbac
Hi,
I think it's not so much XML as custom widgets.
Some plugs will probably work better with specialised widgets that is perhaps
only applicable to this particular plugin.
Also there are some plugs where the GUI clearly adds clarity by using
alternative visualisation. I'm for instance thinki
Steve Harris wrote:
> On Thu, Mar 14, 2002 at 10:28:42 +0100, Stefan Kost wrote:
>
>>Hi Steve,
>
>
> Hi.
>
>
>>>Thats fine for v. simple things, but things that really need guis can't be
>>>easily described in XML, eg.
>>>http://plugin.org.uk/releases/guis/harmonic_gui-0.2.png
>>>http://plugi
On Thu, Mar 14, 2002 at 10:28:42 +0100, Stefan Kost wrote:
> Hi Steve,
Hi.
> > Thats fine for v. simple things, but things that really need guis can't be
> > easily described in XML, eg.
> > http://plugin.org.uk/releases/guis/harmonic_gui-0.2.png
> > http://plugin.org.uk/releases/guis/delayorama
Hi Steve,
> On Wed, Mar 13, 2002 at 06:36:50 +0100, Stefan Kost wrote:
>
>>I would favour if the plugin just supplies functional-desc. und the users
>>chooses the style related things by choosing a theme.
>>
>
> Thats fine for v. simple things, but things that really need guis can't be
> easily
On Wed, Mar 13, 2002 at 06:36:50 +0100, Stefan Kost wrote:
> I would favour if the plugin just supplies functional-desc. und the users
> chooses the style related things by choosing a theme.
Thats fine for v. simple things, but things that really need guis can't be
easily described in XML, eg.
ht
Hi Paul,
>>A system like this could easily generate a simple plugin GUI (like a array of
>>sliders) in whichever UI-toolkit
>>
>
> its worth noting that this works already for LADSPA plugins without
> any GUI specification at all. its how GLAME, ecamegapedal, ardour, snd
> and many others build
>A system like this could easily generate a simple plugin GUI (like a array of
>sliders) in whichever UI-toolkit
its worth noting that this works already for LADSPA plugins without
any GUI specification at all. its how GLAME, ecamegapedal, ardour, snd
and many others build plugin GUIs - they jus
>>Anyway, *why* are people doing this "hidden event loop" thing over
>>and over again...? I've implemented several simple GUI toolkits for
>>various environments, and I haven't really seen a case where chosing
>>between that model and an "open" read_event() + process_event() style
>>interface
On Sunday 10 March 2002 03.10, Paul Davis wrote:
[...event loop...]
> i think there are a couple of reasons. an event loop featuring only
> one source is trivial to write. it gets more difficult when it
> involves more than one, then more difficult still if the event
> sources are of different "ty
>> The problem isn't making chrome easy. It isn't the available
>> widgets. Its the presence of an event loop that is incompatible
>> with another toolkit. At least, thats the problem that I see and
>> was referring to.
[ ... ]
>Anyway, *why* are people doing this "hidden event loop" thing over
On Tuesday 05 March 2002 16.14, Paul Davis wrote:
> >I still think there is, but I'm not so sure it's actually
> > something that can be implemented with a reasonable amount of
> > work. I believe the problem with any new toolkit of the
> > traditional kind is that it would either be too restricti
On Tue, Mar 05, 2002 at 12:57:09 +, David Riley wrote:
> > steve has used it to write GUIs for two of his more complex LADSPA
> > plugins.
>
> Is the source available?
Yep: http://plugin.org.uk/releases/guis/
harmonic is complete, delayorama only outputs; there isn't a 1:1 mapping
between
>I still think there is, but I'm not so sure it's actually something
>that can be implemented with a reasonable amount of work. I believe
>the problem with any new toolkit of the traditional kind is that it
>would either be too restrictive, or too hard to learn. (Most) plugin
>coders want to h
On Monday 04 March 2002 15.02, Paul Davis wrote:
[...]
> if you search the archives, i think you will find that defining a
> toolkit is pretty much a lost cause under Linux. i was all ready to
> implement the VSTGUI for Linux (via GTK), but the more i reflected
> upon it, no such solution will w
Paul Davis <[EMAIL PROTECTED]> writes:
> >> There is a gui standard for LADSPA, but no hosts implement it yet. It's
> >> partly a chicken and egg problem, as there are only 2 gui's.
If anyone is working on adding it to a host and needs a client
for testing they may find this useful:
http://www.d
>> But, IMHO, these projects aren't finished yet. Without a GUI
>> standard, the LADSPA specification is half-done. I can appreciate the
>> discussions that have been held so far. I just haven't seen much > movement
>lately.
>
>This is very true. A vst-stlye abstracted GUI interface is a bi
>> There is a gui standard for LADSPA, but no hosts implement it yet. It's
>> partly a chicken and egg problem, as there are only 2 gui's.
>
> Cool. Where's it at? The page at ladspa.org talks about a
>prototype XML GUI spec but it hyperlinks to "http://www.ladspa.org/???";
that's not it. i
On Mon, 4 Mar 2002, Steve Harris wrote:
> On Mon, Mar 04, 2002 at 10:56:22 -0600, Kevin Conder wrote:
> > But, IMHO, these projects aren't finished yet. Without a GUI
> > standard, the LADSPA specification is half-done. I can appreciate the
> > discussions that have been held so far. I just
On Mon, 4 Mar 2002 17:39:21 +
Steve Harris <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 04, 2002 at 10:56:22 -0600, Kevin Conder wrote:
> > But, IMHO, these projects aren't finished yet. Without a GUI
> > standard, the LADSPA specification is half-done. I can appreciate the
> > discussions t
On Mon, 04 Mar 2002 10:56:22 -0600 (CST)
Kevin Conder <[EMAIL PROTECTED]> wrote:
> But, IMHO, these projects aren't finished yet. Without a GUI
> standard, the LADSPA specification is half-done. I can appreciate the
> discussions that have been held so far. I just haven't seen much > movem
[ points about JACK ]
all valid. i hope they'll be addressed within the next week or two.
btw, as a programmer, i prefer to start with a working sample program,
and then move on to documentation. both are important. its true that
JACK has only one of them right now, but the second is coming.
-
On Mon, Mar 04, 2002 at 10:56:22 -0600, Kevin Conder wrote:
> But, IMHO, these projects aren't finished yet. Without a GUI
> standard, the LADSPA specification is half-done. I can appreciate the
> discussions that have been held so far. I just haven't seen much movement
> lately.
There is
On Sun, 3 Mar 2002, Paul Davis wrote:
> is there a reason why your program is not written as a
> LADSPA plugin?
> is there a reason why your program is not written as a
> JACK client?
I'm not the Gnome Wave Cleaner guy but I have some opinions
on this particular topic... I can appreciate
On Mon, 18 Feb 2002, Steve Harris wrote:
>> I think ecamegapedal will do what you want.
> Has Kai modified it so it will run when period != 256?
Sort of. :) The CVS-version (which you need (both ecasound and
ecamegapedal) for JACK), uses libecasound with buffering profile
"rtlowlatency". The def
On Mon, Feb 18, 2002 at 11:05:03 -0500, Taybin Rutkin wrote:
> On Mon, 18 Feb 2002, Steve Harris wrote:
>
> > Well, ecasound has jack support (only in cvs I think), and run's LADSPA
> > plugins, but I'd hesitate to call it simple!
>
> I think ecamegapedal will do what you want.
Has Kai modified
On Mon, 18 Feb 2002, Steve Harris wrote:
> Well, ecasound has jack support (only in cvs I think), and run's LADSPA
> plugins, but I'd hesitate to call it simple!
I think ecamegapedal will do what you want.
Taybin
On Mon, Feb 18, 2002 at 01:36:15 +0100, Jan-Mark Batke wrote:
>
> Btw: is there a simple ladspa host using jack for audio? Maybe thats
> the right mixture.
Well, ecasound has jack support (only in cvs I think), and run's LADSPA
plugins, but I'd hesitate to call it simple!
- Steve
Paul Davis <[EMAIL PROTECTED]> writes:
> > 1) existing plugins that do this
1.1 Yes, there is
http://jezabel.sourceforge.net
Plugins for alsa, wav-files and so on.
Important note: these plugins use a extended version of
ladspa (see homepage). This is necessary to make the
jezabel plugins conf
> 1) existing plugins that do this
> 2) glaring reasons not to bother
2.1 all existing LADSPA hosts except "applyplugin" already have their own
connections to audio interfaces.
2.2 most hosts have design restrictions on how they interact with
audio interfaces.
2.3 most hosts use some
Hi all,
I've just discovered LADSPA, and like what I see (the 'S' in particular is
appreciated!)
I'm considering writing a few plugins that talk to OSS, ALSA and the aRts
soundserver - before I start, is anyone aware of:
1) existing plugins that do this
2) glaring reasons not to bother
Ch
Steve Harris hat gesagt: // Steve Harris wrote:
> On Tue, Feb 12, 2002 at 11:56:23 +0100, Frank Barknecht wrote:
> >
> > As much as I like your way and as much as I would like to understand it
> > better, I would prefer a more general C or even better C++ tutorial.
> > Making the work easier wit
>> alsa, "properly linked" means either learning quite a lot about the
>> linker or using libtool, neither one of which i relish :)
>
>Libtool won't* correctly build LADSPA plugins. It thinks the're libraries
>and makes some assumptions.
i got it to work for quasimodo plugins. but yes, it is tric
Hi,
[EMAIL PROTECTED] wrote:
> There is also a graphical program that creates the XML, GDAM. The link to
> it on ladspa.org is dead though.
Yes, that should be http://www.ffem.org/gdam nowadays.
Frank
On Wed, Feb 13, 2002 at 10:16:42 -0500, Taybin Rutkin wrote:
> > More or less. Some of them include static libraries written in C. For eg.
> > gverb, which was written by Juhana Sadeharju, there is just a simple XML+C
> > wrapper that calles the library functions.
>
> There is also a graphical pr
On Wed, 13 Feb 2002, Steve Harris wrote:
> > > generate the raw C source. I think it saves a lot of grunt work,
> > > but it
> >
> > That would be super cool! Is that how you make all of your plugins?
>
> More or less. Some of them include static libraries written in C. For eg.
> gverb, which w
On Tue, Feb 12, 2002 at 03:57:37 -0500, Paul Davis wrote:
>
> alsa, "properly linked" means either learning quite a lot about the
> linker or using libtool, neither one of which i relish :)
Libtool won't* correctly build LADSPA plugins. It thinks the're libraries
and makes some assumptions.
- S
On Tue, Feb 12, 2002 at 11:56:23 +0100, Frank Barknecht wrote:
> (The makestub.pl indeed needs a cleanup. I found myself constantly
> cleaning up my Perl code, so I am now happily learning and coding in
> Python, but that shall not start a Perl-Python discussion, please.)
Yes, I tried to give up
On Tue, Feb 12, 2002 at 11:56:23 +0100, Frank Barknecht wrote:
>
> As much as I like your way and as much as I would like to understand it
> better, I would prefer a more general C or even better C++ tutorial.
> Making the work easier with XML and Perl might be too off-topic in the
> tutorial I a
On Tue, Feb 12, 2002 at 01:16:18 -0800, Tim Westbrook wrote:
>
> > You've seen how I do it, write it in XML wrapped C, then use perl
> > to
> > generate the raw C source. I think it saves a lot of grunt work,
> > but it
>
> That would be super cool! Is that how you make all of your plugins?
Mor
> PS The analogue oscilator that I used to distrubte was very
> very bad. It's
> removed in the current release. I will write another when I
> have a good
> understanding of band-limited oscilators.
>
Then write just a sine osc.
-Mikko
Hi,
Steve Harris hat gesagt: // Steve Harris wrote:
> You've seen how I do it, write it in XML wrapped C, then use perl to
> generate the raw C source. I think it saves a lot of grunt work, but it
> won't be to everyones taste. I would be happy to write a tutorial if
> anyone else is interested i
> alsa, "properly linked" means either learning quite a lot about the
Now that's a nice Freudian slip :)
stuart
> You've seen how I do it, write it in XML wrapped C, then use perl
> to
> generate the raw C source. I think it saves a lot of grunt work,
> but it
> won't be to everyones taste. I would be happy to write a tutorial
> if
> anyone else is interested in coding that way.
That would be super cool!
>>> Is it possible to use C++ to write LADSPA plugins? Especially since
>>> the host might only have a C runtime?
>> in general, no its not possible. the (implicit) rule is that the host
>> will only load the shared object containing the plugin(s), so if they
>> require any other symbols to be l
On Tue, 12 Feb 2002, Paul Davis wrote:
>> Is it possible to use C++ to write LADSPA plugins? Especially since
>> the host might only have a C runtime?
> in general, no its not possible. the (implicit) rule is that the host
> will only load the shared object containing the plugin(s), so if they
>> While we're at the subject of LADSPA, I would like to ask, if there's
>> somewhere a real beginner's tutorial for writing ladspa plugins. I
>> just started coding in C++. I have read several C++-books, but I only
>
>Is it possible to use C++ to write LADSPA plugins? Especially since the
>host
Taybin Rutkin hat gesagt: // Taybin Rutkin wrote:
> Is it possible to use C++ to write LADSPA plugins? Especially since the
> host might only have a C runtime?
It should be no problem, for example the whole cmt collection on ladspa.org
is written in C++ and runs on C hosts like PD.
Ciao
--
On Tue, 12 Feb 2002, Frank Barknecht wrote:
> While we're at the subject of LADSPA, I would like to ask, if there's
> somewhere a real beginner's tutorial for writing ladspa plugins. I
> just started coding in C++. I have read several C++-books, but I only
Is it possible to use C++ to write LADS
On Tue, Feb 12, 2002 at 05:17:03 +0100, Frank Barknecht wrote:
>
> While we're at the subject of LADSPA, I would like to ask, if there's
> somewhere a real beginner's tutorial for writing ladspa plugins. I
> just started coding in C++. I have read several C++-books, but I only
> have real program
Steve Harris hat gesagt: // Steve Harris wrote:
> On Tue, Feb 12, 2002 at 02:37:02 +0100, Frank Barknecht wrote:
> > One could also port rx-saturno to a LADSPA plugin, or a jackit
> > client, and everyone could use it in their favourite hosts.
>
> Yep, though this does seem like a lot of wasted
I like this idea. any reason why it wasn't considered before? C
guarentees structs are laid out in order so you should be backwards
compatable. plus it doesn't eat up as many bits for future extension.
LADSPA really needs this.
John
On Wed, Jan 16, 2002 at 09:45:02PM +0100, Richard Guenth
On Wed, 16 Jan 2002, Frank Neumann wrote:
>
> Hi,
> [EMAIL PROTECTED] wrote:
>
> > Paul's suggested addition to handle defaults looks like:
>
> [..]
>
> Just one small nitpicker here:
>
> > #define LADSPA_HINT_DEFAULT_MID0x200 /* set to min+(max-min/2) */
>
> Make that "/* set to
On Wed, Jan 16, 2002 at 08:42:02 -, Richard W.E. Furse wrote:
> Okay, I'll try to find time to sort this one out. Do you need it right now,
> or can I leave it for a bit? I'd prefer to do it very slightly differently
> (I'd prefer not to use so many bits plus ideally I'd also like to be able t
On Wed, 16 Jan 2002, Steve Harris wrote:
> Late last year there was some discussion about LADSPA 1.1, the defaults
> issue still needs resolving, so can we agree on it?
>
> Paul's suggested addition to handle defaults looks like:
>
> -
; -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Steve
> Harris
> Sent: 16 January 2002 15:27
> To: Linux-audio-dev
> Subject: [linux-audio-dev] LADSPA 1.1
>
>
> Late last year there was some discussion about LADSPA 1.1, the defaults
On Wed, 16 Jan 2002, Frank Neumann wrote:
>
> Hi,
> [EMAIL PROTECTED] wrote:
>
> > Paul's suggested addition to handle defaults looks like:
>
> [..]
>
> Just one small nitpicker here:
>
> > #define LADSPA_HINT_DEFAULT_MID0x200 /* set to min+(max-min/2) */
>
> Make that "/* set to
701 - 800 of 884 matches
Mail list logo
