On Mon, Jun 15, 2009 at 04:37:09PM +0200, Lennart Poettering wrote:
On Mon, 15.06.09 15:34, Stéphane Letz (l...@grame.fr) wrote:
What I'm personally trying to achieve is a more flexible way (compared
to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
control component
hi everybody!
thanks for sharing your thoughts!
Jörn Nettingsmeier wrote:
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but
2009/6/18 Jörn Nettingsmeier netti...@folkwang-hochschule.de
hi everybody!
thanks for sharing your thoughts!
Jörn Nettingsmeier wrote:
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a
phaser.
On Wed, 2009-06-17 at 03:07 +1000, Fraser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Robillard wrote:
Sounds an awful lot like units to me... degrees out of 360 is a cyclic
unit
Declaring the control as being in some angle UOM isn't enough to know if the
control is
On Thu, 18.06.09 16:09, torb...@gmx.de (torb...@gmx.de) wrote:
I think org.jackaudio.service should be fine. I don't think this
automatic logic needs to work on non-D-Bus jack builds. As I see it
you don't need to make any changes on jack for this to work. All I
need is the guarantee that
On Wed, 2009-06-17 at 17:16 -0800, Patrick Stinson wrote:
While CPython is more than capable of running fast enough in the audio
thread for control-rate (MIDI) work
eeehhh no ;)
Python is nowhere even remotely near realtime safe, unless you're doing
some clever allocation stuff etc.?
-dr
hi everybody!
as discussed in another thread, i would like to propose a new LADSPA
release 1.2, which should include the following changes:
1. addition of a port range hint flag LADSPA_HINT_PERIODIC to denote
periodic behaviour of a control port to be added to the
Lennart Poettering wrote:
PA does not use fixed block sizes. We always use the largest chunk
sizes the applications pass to us and break them up into smaller
pieces only when really necessary. We really try our best not having
to touch/convert/split/copy user supplied PCM data if we don't have
Fons Adriaensen wrote:
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set
2009/6/18 Stefano D'Angelo zanga.m...@gmail.com:
You might want to talk to Richard Furse as well about this, who is the
author of LADSPA and IIRC he told me he wasn't reading LAD mails lately. You
can find his email at the bottom of the main www.ladspa.org page.
Richard is one of the authors
2009/6/18 Paul Davis p...@linuxaudiosystems.com
2009/6/18 Stefano D'Angelo zanga.m...@gmail.com:
You might want to talk to Richard Furse as well about this, who is the
author of LADSPA and IIRC he told me he wasn't reading LAD mails lately.
You
can find his email at the bottom of the
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: is lrdf simple and
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano D'Angelo wrote:
Host will need to use the value (UpperBound + 1) no matter
where these strings get stored. A host looping over the port
data should just initialise a pointer:
const char **enum_labels = descriptor-PortNames +
On Thu, 18.06.09 13:51, Paul Davis (p...@linuxaudiosystems.com) wrote:
On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering mz...@0pointer.dewrote:
This is a bit more complex than you might think. Jack's thread
management is very unflexible and insists on controlling the entire
2009/6/18 Luis Garrido luisgarr...@users.sourceforge.net
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits,
2009/6/18 Stefano D'Angelo zanga.m...@gmail.com:
2009/6/18 Luis Garrido luisgarr...@users.sourceforge.net
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I
On Thu, Jun 18, 2009 at 2:45 PM, Lennart Poetteringmz...@0pointer.de wrote:
So, how would I use this? I figure something like this:
snip
void* my_thread(void*arg) {
for (;;) {
n = jack_cycle_wait(client);
process_my_data(n);
jack_cycle_signal(client, 0);
[Fons Adriaensen]
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are appended to the
struct.
(That is not to say it's hugely preferable
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano D'Angelo wrote:
Host will need to use the value (UpperBound + 1) no matter
where these strings get stored. A host looping over the port
data should just initialise a pointer:
const char
On Thu, Jun 18, 2009 at 08:46:28PM +0200, Stefano D'Angelo wrote:
3. Do as Fons suggested (which to me sounds like make that tiny part of the
API a bit counter-intuitive);
It's just a conceptual change. The port_names array
becomes a general-purpose string table, the first
NPORT values are the
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not
On Thu, 18.06.09 20:12, Jussi Laako (ju...@sonarnerd.net) wrote:
Lennart Poettering wrote:
PA does not use fixed block sizes. We always use the largest chunk
sizes the applications pass to us and break them up into smaller
pieces only when really necessary. We really try our best not
David Robillard wrote:
Python is nowhere even remotely near realtime safe, unless you're doing
some clever allocation stuff etc.?
I don't know the internals of the CPython interpreter, but I'd say it's
safe to assert that Python does its own memory management. Python should
be perfectly capable
On Thu, 18.06.09 14:49, Paul Davis (p...@linuxaudiosystems.com) wrote:
So, to map this to JACK, I would prefer if jack_cycle_wait() would
also exist in a non-blocking variant. i.e. something that can return 0
if there's nothing to process, but doesn't necessarily wait.
that's not
On Thu, Jun 18, 2009 at 08:54:39PM +0200, Stefano D'Angelo wrote:
You would have to add the names in order of (port index, value),
starting from PortNames + PortCount... is this really so intuitive to
someone who occasionaly does C?
Should someone who 'occasionaly does C' write a
plugin host
On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze wrote:
[Fons Adriaensen]
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are
Lennart Poettering wrote:
If an application can send PA data in larger blocks then we are happy
about it and take it. Of course, if the application needs low
latencies then it shouldn't pass huge blocks to us, but instead many
No, generally data needs to be fed _to_ application immediately
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum *
On Thu, 18.06.09 23:27, Jussi Laako (ju...@sonarnerd.net) wrote:
Lennart Poettering wrote:
If an application can send PA data in larger blocks then we are happy
about it and take it. Of course, if the application needs low
latencies then it shouldn't pass huge blocks to us, but instead
2009/6/18 Damon Chaplin da...@karuna.eclipse.co.uk:
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze wrote:
[Fons Adriaensen]
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
Hi,
On 18.06.2009, at 22:27, Jussi Laako wrote:
No, generally data needs to be fed _to_ application immediately when
it
becomes available after A/D conversion (PCI DMA completion interrupt).
Application(s) process the data and it is ought to go to D/A
conversion
on next hardware
2009/6/18 Tim Goetze t...@quitte.de:
[Stefano D'Angelo]
Note: a weird host could copy make a copy of the descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C languages (why does Java
Hi,
On Thursday 18 June 2009 23:16:53 Tim Goetze wrote:
[Stefano D'Angelo]
Note: a weird host could copy make a copy of the descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C
On Thu, Jun 18, 2009 at 10:50:45PM +0200, Stefano D'Angelo wrote:
Now, suppose you wanted to add other kind of stuff in some future to
ports: if they are strings, you could do this thing once again (maybe,
maybe not), if they are not strings (e.g. units of measure as an
enum), how to do that
On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poetteringmz...@0pointer.de wrote:
On Jack we have jack_frames_since_cycle_start(), would it be
considered an ugly hack if I use that to implement a similar logic?
for (;;) {
n = jack_client_wait()
process(n);
jack_cycle_signal();
while
On Thu, Jun 18, 2009 at 11:23:52PM +0200, Arnold Krille wrote:
But if the plugin is v1.2 and the host is v1.1 doesn't this mean the host
only
used v1.1 at compile time? Then on copying the struct or on doing pointer-
arithmetic it will only know the old size of the struct and definitely
On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote:
Sorry, didn't see that. Well, I guess there's no problem on the plugin
side then... any other possible problems on the host side?
In case there are none, we could add an array or another callback.
You'd need a way to let the host
On Thu, 18.06.09 17:41, Paul Davis (p...@linuxaudiosystems.com) wrote:
On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poetteringmz...@0pointer.de wrote:
On Jack we have jack_frames_since_cycle_start(), would it be
considered an ugly hack if I use that to implement a similar logic?
for (;;)
Stefano D'Angelo wrote:
You're right. Well, I vote for the extra function and leaving
descriptor untouched too.
The extra function seems best to me as well. Sort of DSSI-like approach
(and DSSI obviously works!).
Krzysztof
___
Linux-audio-dev
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
Plus, you can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
You can. Fields are not referred to by name in compiled
On Fri, 19.06.09 01:56, Jussi Laako (ju...@sonarnerd.net) wrote:
Lennart Poettering wrote:
Yeah? And this matters how to PA?
Only in a way as I said, goals of JACK and PA are different, they try to
solve different problem and naturally use different means to achieve
these goals.
This
On Fri, 19.06.09 01:23, Fons Adriaensen (f...@kokkinizita.net) wrote:
On Fri, Jun 19, 2009 at 12:33:24AM +0200, Lennart Poettering wrote:
This is basically what happens. However in PA we are much more dynamic
than JACK generally is. JACK clients generally just have a single
stream of
2009/6/19 Fons Adriaensen f...@kokkinizita.net
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
Plus, you can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
On Thu, Jun 18, 2009 at 7:43 PM, Lennart Poetteringmz...@0pointer.de wrote:
snip
for (;;) {
n = jack_client_wait()
process(n);
jack_cycle_signal();
while (jack_frames_since_cycle_start() threshold) {
if (no_private_events_to_process())
break;
On Thu, 18.06.09 19:57, Paul Davis (p...@linuxaudiosystems.com) wrote:
On Thu, Jun 18, 2009 at 7:43 PM, Lennart Poetteringmz...@0pointer.de wrote:
snip
for (;;) {
n = jack_client_wait()
process(n);
jack_cycle_signal();
while (jack_frames_since_cycle_start()
On Thu, Jun 18, 2009 at 8:27 PM, Lennart Poetteringmz...@0pointer.de wrote:
But for MIDI time is critical. For my control events it is not. That's
why I'd like to handle them after the _signal() invocation.
fair enough, but you definitely cannot use
jack_frames_since_cycle_start() there. there
48 matches
Mail list logo
