Hi,
I'm attempting to use dlsym to dynamically load a ladspa plugin lib in
c++. I've found various web pages describing how to use dlsym in c++
but they do not seem entirely relevant to using ladspa (ie ladspa
plugins are mainly written in c) (??).
I've also looked at some ardour src, but somehow it seems to use, in a
c++ file, the c method which should not work (!?). I also looked within
hydrogen src, but that seems to use QT(?) to do the loading - and
delving into the QT src code does not appeal right now ;-)
Anybody know where could I find some simple c++ source examples for
loading ladspa plugins?
Cheers,
James
Christian Schoenebeck cuse at users.sourceforge.net:
>Am Donnerstag, 15. November 2007 18:51:30 schrieb Kjetil S. Matheussen:
>> *The msys terminal is a lot nicer than xterm
>> *msys/mingw uses fewer resources than cygwin
>> *mingw executables requires fewer dlls and are easier to
>> distribute
>> *mingw executables can be linked with non-cygwin dll's.
>>
>> disadvantages:
>> *msys/mingw is messy to set up. Check out the FAQ first.
>> *msys/mingw is very messy to upgrade.
>> (manually unpacking .tar files into the file tree)
>> *msys doesn't provide the same amount of unix tools.
>> *mingw executables can not be linked with cygwin dll's.
>
>That's not a real either/or question. Mingw is part of Cygwin as well:
>
> http://cygwin.com/packages/
>
>So you can easily setup and update both with just a few clicks in the
>cygwin
>install utility.
Sure, but then you have to use the -mno-cygwin option to gcc
when compiling, which sometimes can be tricky. So my comparison
above is still valid, and you don't need cygwin to run mingw.
The msys terminal is very nice, and I don't see any reason
to fire up the whole cygwin[1] beast to compile a native
windows app now and then, unless you need something in
cygwin which is not provided by msys of course.
I also think its messy to mix the mingw and cygwin
environments, since they are not compatible. Its easy to
link with libraries of the other type (ie. compiling
with mingw and link with cygwin libraries, or compiling
with cygwin and link with mingw libraries), and then
strange things can happen. Its better to keep the two
environments in separate installations if you can.
At least thats my experience.
[1] X running inside windows is required to make working
with cygwin somewhat comfortable
>One thing I wonder is whether mingw has any disadvantages regarding
>compiler
>optimizations?
No, that would be very strange.
> You know the term "minimalistic" in its name raises such
>doubts.
I wouldn't worry about that. Gcc is gcc.
>Maybe... I considered Control as well, but to me, both of those sound
more like single instances of something (just like Ports), rather
than the Class/Type style (ie "Voice Pitch Controls") term I'm
looking for.
>*Some* plugin API or something somewhere must have something similar
to this, I'd think, but I can't remember seeing one...
My plugin API has parameters , pins ( similar to ports ) and 'voices'.
The relationship is that parameters map to pins, and controllers map to
pins.
For example:
pin 0 - "Master Volume" (parameter, monophonic).
Pin 1 - "Note Pitch" (controller, polyphonic, mapped to MIDI
Note-On/Pitch).
Pin 3 - "Tempo" (monophonic, mapped to host tempo).
The host decodes MIDI and maps controllers to pins. The plugin API need not
support MIDI at all (yay!), you could migrate to using OSC messages just as
easily with no change to your plugin code.
The end result is that the plugin API is *very* minimal, 3 functions support
most of the GMPI requirements...
class IMpPlugin : public IMpUnknown
{
public:
// Processing about to start. Allocate resources here.
virtual int32_t MP_STDCALL open() = 0;
// Notify plugin of audio buffer address, one pin at a time. Address
may change between process() calls.
virtual int32_t MP_STDCALL setBuffer( int32_t pinId, float* buffer )
= 0;
// Process a time slice. No Return code, must always succeed.
virtual void MP_STDCALL process( int32_t count, MpEvent* events ) =
0;
};
Jeff
David Olofson:
>> And last:
>>
>> If I can only do it native Windows, what do I need in the way of
>> compiler etc. ?
>
> Cygwin is probably the easiest way to get started with that, whether
> you're using Wine or Windows:
> http://www.cygwin.com/
>
I depends. For hardcore unix programs, cygwin can in some situations
be the only alternative. But msys/mingw has its advantages as well:
*The msys terminal is a lot nicer than xterm
*msys/mingw uses fewer resources than cygwin
*mingw executables requires fewer dlls and are easier to
distribute
*mingw executables can be linked with non-cygwin dll's.
disadvantages:
*msys/mingw is messy to set up. Check out the FAQ first.
*msys/mingw is very messy to upgrade.
(manually unpacking .tar files into the file tree)
*msys doesn't provide the same amount of unix tools.
*mingw executables can not be linked with cygwin dll's.
http://www.mingw.org/msys.shtml
Not sure if this is a hard problem, or if I'm just being extra stupid
today...
Assume we have a 2D addressing scheme for addressing Ports on a
plugin. A Port here can be a connection that sends or receives a
single mono audio stream, control data for a single parameter, or
something like that.
The first dimension is similar to MIDI CCs, or the different types of
controls in a mixer strip. The coordinate indicates what kind or
group of control/port/whatever we're talking about. Examples: "Master
volume control" (probably just one of these) and "channel pitch
controls" (one per channel, obviously). On a (normal) studio mixer,
we'd be talking about a horizontal row of controls, all of the same
kind.
The second dimension is similar to MIDI channels, synth voices, or
mixer channels, depending on context. I'm calling all this "Channel",
as that's the least domain specific name I can think of that still
makes sense. Basically, when you have multiple indentical internal
objects, this is how you address the instances.
Now, what do I call the first dimension, *before* specifying what
channel I'm talking about? How do I address "the Volume CCs of all 16
MIDI channels", or "the PFL buttons of all mixer strips?" I'd like a
short, logical, non-confusing name for this, but I can't seem to
think of one.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
David Olofson <david(a)olofson.net> writes:
> On Monday 05 November 2007, Nedko Arnaudov wrote:
>> Purpose of this LV2 extension is to standardize realtime safe
>> allocations in a plugin. Plan is, host to provide functions that
>> plugin can call. Pointers to functions are provided through host
>> feature. Only memory pool (fixed chunk size) functionality is
>> defined.
>>
>> Attached is early draft of the header. Doxygen generated from it
>> documentation is available at:
>>
>>
> http://svn.gna.org/viewcvs/*checkout*/lv2dynparam/website/doxygen/lv2__rtme…
>>
>> Any comments are welcome. In particular about whether general
>> purpose allocator (arbitrary memory chunk size) should be part of
>> this same extension.
>
> I'm not quite sure I see the point of having hosts provide this level
> of functionality. A pool of fixed size chunks is trivial to implement
> on the plugin side.
>
> The only obvious advantage I see is the potential transparent host
> side sharing of memory across plugins - but this gets tricky to
> implement when plugins request different chunk sizes. Sure, the host
> can split and merge chunks and stuff as needed, but then you may as
> well go all the way, as you'll need a real memory manager behind the
> scenes anyway.
The point is that some plugins need *realtime safe* memory allocation. I
need this functionality for lv2zynadd plugin (like arbitrary voices
count allocation) and for lv2dynparam plugin library internal operation
too. There were rumors in #lad that such functionality may be useful
without lv2dynparam extension. This has lead to this proposal. But if
there are no positive opinions for this extension I'll integrate it into
lv2dynparam extension.
That reminds me that LV2 may need a way to specify optional features
that interdepend. I.e. features (extensions) A and B are both optional
but if A is provided B is required. Of course plugin can check this
explicitly on instantiate and refuse to use feature, but I'm not sure
how vital is such approach.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Dear all,
The online form for the submission of papers for LAC2008 is now open!
Authors please use the conference management system at
http://lac.linuxaudio.org/openconf
The deadline for paper submissions is 1 Dec 2007.
We invite submissions of papers addressing all areas of audio
processing based on Linux and open source software. Papers can focus
on technical, artistic or scientific issues and can target developers
or users. For details please refer to the call for papers below and on
the web at
http://lac.linuxaudio.org
We would also like to remind you of the call for music. We are
looking for music that has been produced completely or mostly under
Linux and/or with open source software from every genre: compositions,
Electronica, Chill-Out, Ambient, etc.
The deadline for music submissions is 1 Dec 2007.
On behalf of the LAC2008 organisation team, sincerely,
Frank Barknecht and Martin Rumori
Dave Robillard wrote:
> Heavy handed over-definition like this is exactly what LV2 is designed
> to avoid ;)
And what's the intention behind it? What do you intend to achieve with LV2?
I mean, freedom is good, but predictable behaviour and maximum
compatibility between implementations is one of the reasons behind
standardisation, in my opinion.
By "predictable behaviour" I mean predictable to non-technical end
users, not just to developers. I don't know how many non-technical end
users do you know, but you may bet that once you start describing
feature sets in hosts and plugins they'll go "lalala I can't hear you" :)
Also, notice that introducing those "levels" doesn't prevent
custom/proprietary features in any way. Which is why my proposal is all
but "heavy handed". The only thing it's "heavy handed" about is
promoting implementation of basic infrastructure in hosts. Just like
power socket standard is heavy handed about the voltage and physical
layout/function of the pins.
I think you should ask people with more experience about history of
standards like DX, VST or Buzz - evolution, early bugs, what features
did they offer and how they were used etc. Otherwise, you're doomed to
repeat the same mistakes the authors of those standards had made. Which
will possibly mean "death by arrogance" of the new standard.
There's an old saying (I don't know who coined it) - "those who don't
know Unix are doomed to reinvent it, poorly" - I think it's the same
with all kinds of plugin APIs.
Krzysztof
(sorry, i'm reposting this because for some unknown reason the
previous mail ended up in the wrong thread tree)
hello,
i'm looking for people interested in developing a java /
supercollider based audio file editor "Eisenkraut". this is a
crossplatform / open source project that needs to be taken off my
shoulders in the long term. the most important current step is the
proper implementation of an osc interface to communicate with
supercollider.
here's the relevant links:
http://sciss.de/eisenkrauthttp://sourceforge.net/projects/eisenkraut
(--> find there downloads, mailing list, bug tracker)
thanks for your attention!
ciao, -sciss-
hello,
i'm looking for people interested in developing a java /
supercollider based audio file editor "Eisenkraut". this is a
crossplatform / open source project that needs to be taken off my
shoulders in the long term. the most important current step is the
proper implementation of an osc interface to communicate with
supercollider.
here's the relevant links:
http://sciss.de/eisenkrauthttp://sourceforge.net/projects/eisenkraut
(--> find there downloads, mailing list, bug tracker)
thanks for your attention!
ciao, -sciss-
