22 Apr
2013
22 Apr
'13
5:33 a.m.
Hi,
These last few days I found some time to work on ladspa.m.lv2, an LV2
plugin to load ladspa.m.proto instrument definition files:
https://github.com/fps/ladspa.m.lv2
It is in a somewhat usable state, i.e. used in ardour3 it loads the
example instrument generated by this python script:
https://github.com/fps/ladspa.m.proto/blob/master/example_instrument.py
which is a very simple polyphonic sawtooth synth with exponential
envelopes and an echo with differing delay times per voice. There's
still some things to do (e.g. expose control ports, implement
All-Notes-Off midi messages, lots of optimizations - right now I care
more for correctness than for efficiency, etc.) and I also have some
questions:
1] This one is regarding waf. I'm not used to writing wscript files and
I adapted the whole thing from the example sampler from the
LV2-distribution. I wonder how I can make waf to use e.g. -fPIC and
other compiler flags needed for my 64-bit system. Right now I have put a
little makefile into the repository which passes the missing options
along as CXXFLAGS environment variable. This is a dirty hack. So if
anyone waf guru might want to take a look, I'd be so ever grateful.
https://github.com/fps/ladspa.m.lv2/blob/master/makefile
https://github.com/fps/ladspa.m.lv2/blob/master/wscript
2] I'm a little bit puzzled by how the patch_set messages together with
the LV2 worker extension works. If you take a look at this run() function
https://github.com/fps/ladspa.m.lv2/blob/master/instrument.cc#L702
you'll see that I have an extra LV2_ATOM_SEQUENCE_FOR_EACH at the start
of the function to process the patch_set messages. I tried to integrate
that into the loop later on (that iterates over the sample_count frames
and lets the midi events take effect at their respective frame), but
once I do that, patch loading stops to work. I must be missing something
fundamental. So if any LV2 guru might want to take a look, I'd be very
grateful, too
Thanks and have fun,
Flo
--
Florian Paul Schmidt
http://fps.io
23 Apr
23 Apr
10:47 a.m.
Am 22.04.2013 07:33, schrieb Florian Paul Schmidt:
Hi,
These last few days I found some time to work on ladspa.m.lv2, an LV2
plugin to load ladspa.m.proto instrument definition files:
https://github.com/fps/ladspa.m.lv2
It is in a somewhat usable state, i.e. used in ardour3 it loads the
example instrument generated by this python script:
https://github.com/fps/ladspa.m.proto/blob/master/example_instrument.py
which is a very simple polyphonic sawtooth synth with exponential
envelopes and an echo with differing delay times per voice. There's
still some things to do (e.g. expose control ports, implement
All-Notes-Off midi messages, lots of optimizations - right now I care
more for correctness than for efficiency, etc.) and I also have some
questions:
1] This one is regarding waf. I'm not used to writing wscript files
and I adapted the whole thing from the example sampler from the
LV2-distribution. I wonder how I can make waf to use e.g. -fPIC and
other compiler flags needed for my 64-bit system. Right now I have put
a little makefile into the repository which passes the missing options
along as CXXFLAGS environment variable. This is a dirty hack. So if
anyone waf guru might want to take a look, I'd be so ever grateful.
https://github.com/fps/ladspa.m.lv2/blob/master/makefile
https://github.com/fps/ladspa.m.lv2/blob/master/wscript
Hi
I'm far from being a waf expert, but I will try to help you out here:
You can use
conf.env['cshlib_LINKFLAGS'].append("-fPIC")
or
conf.env['shlib_LINKFLAGS'].append("-fPIC")
or
conf.env['cxxshlib_LINKFLAGS'].append("-fPIC")
somewhere in the def configure(conf): part to set the link flag
and you can use in the obj = bld
cflags = '-Wall -O3 -march=native',
or
cxxflags = '-Wall -O3 -march=native',
depending on your seated
obj = bld(features = 'c cshlib',
or
obj = bld(features = 'cxx cxxshlib',
greets
hermann
2] I'm a little bit puzzled by how the patch_set messages together
with the LV2 worker extension works. If you take a look at this run()
function
https://github.com/fps/ladspa.m.lv2/blob/master/instrument.cc#L702
you'll see that I have an extra LV2_ATOM_SEQUENCE_FOR_EACH at the
start of the function to process the patch_set messages. I tried to
integrate that into the loop later on (that iterates over the
sample_count frames and lets the midi events take effect at their
respective frame), but once I do that, patch loading stops to work. I
must be missing something fundamental. So if any LV2 guru might want
to take a look, I'd be very grateful, too
Thanks and have fun,
Flo
11:37 a.m.
On 04/23/2013 12:47 PM, hermann meyer wrote:
Am 22.04.2013 07:33, schrieb Florian Paul Schmidt:
Hi
I'm far from being a waf expert, but I will try to help you out here:
You can use
conf.env['cshlib_LINKFLAGS'].append("-fPIC")
or
conf.env['shlib_LINKFLAGS'].append("-fPIC")
or
conf.env['cxxshlib_LINKFLAGS'].append("-fPIC")
somewhere in the def configure(conf): part to set the link flag
and you can use in the obj = bld
cflags = '-Wall -O3 -march=native',
or
cxxflags = '-Wall -O3 -march=native',
depending on your seated
obj = bld(features = 'c cshlib',
or
obj = bld(features = 'cxx cxxshlib',
Hi, thanks for the info, but I would expect that there's a maybe more
portable way, at least for the -fPIC option>
Flo
--
Florian Paul Schmidt
http://fps.io
25 Apr
25 Apr
6 a.m.
Am 23.04.2013 13:38, schrieb Florian Paul Schmidt:
Hi, thanks for the info, but I would expect that there's a maybe more
portable way, at least for the -fPIC option>
Flo
So you mean command-line options? Or do you look for some automatism?
However, here are command-line options implementations for this:
def options(opt):
opt.load('compiler_c')
autowaf.set_options(opt)
comp = opt.add_option_group ('Set additional build flags', '')
comp.add_option('--cflags',
type='string',
default='-Wall',
dest='cflags',
help='C base compiler flags [Default: %default]')
comp.add_option('--linkflags',
type='string',
default='',
dest='cshlibLINKFLAGS',
help='C base link flags [Default: %default]')
def configure(conf):
conf.load('compiler_c')
autowaf.configure(conf)
autowaf.display_header('Amp Configuration')
opt = conf.options
if opt.cflags:
conf.env['CFLAGS'] += opt.cflags.split()
if opt.cshlibLINKFLAGS:
conf.env['LINKFLAGS_cshlib'] += opt.cshlibLINKFLAGS.split()
[.....]
autowaf.display_msg(conf, "LV2 bundle directory",
conf.env['LV2DIR'])
autowaf.display_msg(conf, "Cflags in use", conf.env['CFLAGS'])
autowaf.display_msg(conf, "Linkflags in use",
conf.env['LINKFLAGS_cshlib'])
greets
hermann
9 May
9 May
8:46 p.m.
On Tue, 2013-04-23 at 12:47 +0200, hermann meyer wrote:
[...]
> 2] I'm a little bit puzzled by how the
patch_set messages together
> with the LV2 worker extension works. If you take a look at this run()
> function
>
> https://github.com/fps/ladspa.m.lv2/blob/master/instrument.cc#L702
>
> you'll see that I have an extra LV2_ATOM_SEQUENCE_FOR_EACH at the
> start of the function to process the patch_set messages. I tried to
> integrate that into the loop later on (that iterates over the
> sample_count frames and lets the midi events take effect at their
> respective frame), but once I do that, patch loading stops to work. I
> must be missing something fundamental. So if any LV2 guru might want
> to take a look, I'd be very grateful, too
(Sorry for the late reply, I don't monitor LAD very closely these days)
You should be able to handle all the events in one loop.
However here you seem to be iterating over all events *for every frame*?
That would cause a problem with loading since you'll issue a ton of
identical load requests, but it also probably isn't what you want for
MIDI either. You'll trigger everything repeatedly and the timing is
wrong. I think you need to unify your two loops here.
The general pattern for sample-accurate event receiving is work through
time in the event loop, outputting everything up to the current event.
So you start with t=0. The next event loop in the loop is at t=5, so
render the output for 0..5, process the event (to e.g. trigger a voice
or whatever), then continue. After the loop output everything from the
last event to the end of the cycle.
So your event processing loop is your processing loop, and proceeds in
'chunks' delimited by events.
The magic of the worker extension is you can do non-RT things like load
new sample banks, which will happen RT-safe (with latency) if running
realtime, but if freewheeling (e.g. for export) the scheduled work will
execute immediately/synchronously. Thus you can get sample accurate
exporting, e.g. with a patch load at t=0 and a note on at t=1 the note
is guaranteed to play with the new patch (in the export). You don't
need to worry about this, but it's why things are the way they are...
plus it's pretty cool :)
Hopefully that makes sense, the simplest example of how to do this is in
the metro example:
http://lv2plug.in/browser/trunk/plugins/eg03-metro.lv2/metro.c#L296
tl;dr: Do that :)
-dr
9:02 p.m.
On 05/09/2013 10:46 PM, David Robillard wrote:
(Sorry for the late reply, I don't monitor LAD
very closely these days)
You should be able to handle all the events in one loop.
However here you seem to be iterating over all events *for every frame*?
That would cause a problem with loading since you'll issue a ton of
identical load requests, but it also probably isn't what you want for
MIDI either. You'll trigger everything repeatedly and the timing is
wrong. I think you need to unify your two loops here.
Nope, I do not iterate over all events in every frame. Before iterating
over the frames I get the first event and then on every frame I iterate
over those events that have that frame time.. This is similar to how the
jack_midi example code does it..
// First the worker events stuff ONCE per run() call
LV2_ATOM_SEQUENCE_FOREACH(self->control_port, ev)
{
[...]
}
// Then the iteration over the frames...
LV2_Atom_Event *ev =
lv2_atom_sequence_begin(&(self->control_port)->body); [...]
for (unsigned frame_index = 0; frame_index < sample_count; ++frame_index)
{
[...]
while (false == lv2_atom_sequence_is_end(&(self->control_port)->body,
self->control_port->atom.size, ev) && ev->time.frames == frame_index)
{
[...]
ev = lv2_atom_sequence_next(ev);
} [...]
// Did we reach the end of a chunk or the last of the sample_count?
if (0 == (frame_index + 1) % buffer_size || sample_count == frame_index + 1)
{
process(self, frame_index % buffer_size + 1, chunk_index * buffer_size);
++chunk_index;
}
}
The general pattern for sample-accurate event
receiving is work through
time in the event loop, outputting everything up to the current event.
So you start with t=0. The next event loop in the loop is at t=5, so
render the output for 0..5, process the event (to e.g. trigger a voice
or whatever), then continue. After the loop output everything from the
last event to the end of the cycle.
So your event processing loop is your processing loop, and proceeds in
'chunks' delimited by events.
The magic of the worker extension is you can do non-RT things like load
new sample banks, which will happen RT-safe (with latency) if running
realtime, but if freewheeling (e.g. for export) the scheduled work will
execute immediately/synchronously. Thus you can get sample accurate
exporting, e.g. with a patch load at t=0 and a note on at t=1 the note
is guaranteed to play with the new patch (in the export). You don't
need to worry about this, but it's why things are the way they are...
plus it's pretty cool :)
Hopefully that makes sense, the simplest example of how to do this is in
the metro example:
http://lv2plug.in/browser/trunk/plugins/eg03-metro.lv2/metro.c#L296
I do use the worker extension. The only problem I saw was when I tried
to integrate the patch_set messages in that same loop.
Flo
--
Florian Paul Schmidt
http://fps.io
9:16 p.m.
On Thu, 2013-05-09 at 23:02 +0200, Florian Paul Schmidt wrote:
On 05/09/2013 10:46 PM, David Robillard wrote:
I see, I misread the code. I suppose that works if you need to iterate
over every frame for other reasons.
(Sorry for the late reply, I don't monitor
LAD very closely these days)
You should be able to handle all the events in one loop.
However here you seem to be iterating over all events *for every frame*?
That would cause a problem with loading since you'll issue a ton of
identical load requests, but it also probably isn't what you want for
MIDI either. You'll trigger everything repeatedly and the timing is
wrong. I think you need to unify your two loops here.
Nope, I do not iterate over all events in every frame. Before iterating
over the frames I get the first event and then on every frame I iterate
over those events that have that frame time.. This is similar to how the
jack_midi example code does it.. I do use the worker extension. The only problem I saw
was when I tried
to integrate the patch_set messages in that same loop.
There shouldn't be a difference. Assuming that, in the integrated case,
you're scheduling the exact same work (easy enough to check) nothing
should be any different, unless something is wrong with the asynchronous
work stuff and some really fine timing problems are happening...
everything looks good though, the work stuff shouldn't be affected by /
affect state...
What kind of problem?
-dr
9:25 p.m.
On 05/09/2013 11:16 PM, David Robillard wrote:
I do use the worker extension. The only problem I saw
was when I tried
to integrate the patch_set messages in that same loop.
There shouldn't be a difference. Assuming that, in the integrated case,
you're scheduling the exact same work (easy enough to check) nothing
should be any different, unless something is wrong with the asynchronous
work stuff and some really fine timing problems are happening...
everything looks good though, the work stuff shouldn't be affected by /
affect state...
What kind of problem?
For some reason patch setting didn't work in this case at all. I
sprinkled some debugging output into the code to see what was up. It
seems the load_instrument function never got called. But before putting
any more effort into diagnosing the problem, I'll take your work as to
that it should really work that way, too. I'll just assume that I messed
up somewhere else and see if I can try to widen my understanding of the
worker extension (I basically built this plugin based on the eg-sampler
plugin from the lv2 distribution, so some parts I just copied and pasted
with only minor adjustments)..
Flo
--
Florian Paul Schmidt
http://fps.io
4097
days inactive
4114
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
3 participants
participants (3)
-
David Robillard -
Florian Paul Schmidt -
hermann meyer