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-
Hi all
As part of a bigger project, I need to develop a module which reads PCM data
from a file and feeds it to sound driver. Is it possible to develop such a
module without actually writing device driver, I mean just by using existing
functions such as snd_pcm_open and all that ? Can someone throw more light
on this ?
Regards,
Avadhoot
hi,
germany uses 'h' in musical scores where most of the rest uses 'b'. Is
that entirely true? Are there other countries that use 'h' as well.
Ideally I look for a table that maps, locales $LANG to h/b.
Stefan
On Thursday 08 November 2007, Nedko Arnaudov wrote:
[...]
> The point is that some plugins need *realtime safe* memory
> allocation.
Well, yes; that part is quite obvious.
What I meant was, if all the host provides is a pool of uniformly
sized chunks that are allocated when the plugin is initialized, there
doesn't seem to be much point in implementing it on the host side.
The naïve host side implementatio would add exactly nothing, compared
to plugins just allocating their own pools during initialization.
A proper real time manager, with arbitrary chunk sizes, would be more
motivated, as it adds functionality that plugins can't implement
internally; namely a shared memory pool.
> I
> need this functionality for lv2zynadd plugin (like arbitrary voices
> count allocation)
The "standard" solution is to pre-allocate and pre-initialize voice
structures for a fixed maximum polyphony.
Obviously, this becomes troublesome with modular synths and the like,
where the "voice structure" doesn't have a fixed size.
One solution is to allocate the voice pool as a response to "program
change" events. Of course, this makes the "programe change" operation
non real time safe, but it usually is anyway, due to samples being
loaded from disk and stuff. Many systems, both hardware and software,
are based entirely on the idea that patch loading is part of
setup/initialization, as that is often the only practical solution.
It's really only entirely ROM based synths (or "small fixed sample
set", in the case of software), virtual analog synths and the like
that *can* implement real time safe "program change" at all.
> and for lv2dynparam plugin library internal
> operation too.
It needs to "regroup" internally as a response to certain parameter
changes?
> There were rumors in #lad that such functionality may be useful
> without lv2dynparam extension.
Well, yes; real time safe dynamic memory management can make life a
lot easier for some types of plugins, and/or reduce memory
requirements by having a shared pool. However, I think it needs to be
more generic than just a pool of fixed size chunks for the "shared
pool" part to be viable.
[...]
> 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.
Haven't really thought about this... Isn't it just a matter of plugins
and hosts listing *all* extensions? I mean, if you provide or ask for
this feature A, but not feature B, you have a bug. An automatic
validation tool would trap this right away - but of course,
someone/something has to tell the *tool* about these extension
interdependencies...
//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 --'
e
i'm using cheap Terratec Aureon 5.1 USB MKII and i'm happy that
through jack i can use 3 output channels coz it supports surround... do
you guys know of some PCI sound card (cheap?) which will have more
than 3 output channels?
i would like to build linux sound box as sooperlooper[1] with topot[2]
which i'm (together with marijn[3]) working on works great.. with more
output channels i can separately send loops to external effect
boxes...
thanx
[1] http://essej.net/sooperlooper/
[2] https://savannah.nongnu.org/projects/topot
[3] http://eloquentjavascript.net/
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.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
