Hello everybody,
is the lv2 plugin group Boolean-oriented from lv2 rdf spec? I find it as
ingen menu item but not in the lv2 rdf spec. Does someone maybe know how
I get into there.
Regards and thank you
Uli
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
LADSPA_PortRangeHintDescriptor bit field.
if present, both LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE must be specified as well. moreover,
both LowerBound and UpperBound must be present in the corresponding
LADSPA_PortRangeHint struct.
the presence of LADSPA_HINT_PERIODIC implies that LowerBound is
equivalent to UpperBound.
hosts should consider displaying a widget that reflects the periodic
nature of the corresponding control value, such as a rotary control.
hosts that interpolate between control values defined by the user
(such as automation points in a DAW) should take into account that
the shortest path between two given values might cross the
boundary defined by LowerBound resp. UpperBound and behave
accordingly.
usage example: soundfield rotators, circular panners
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 numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
some of these mandatory settings are redundant and could be handled
as being implicit.
however, for the sake of backwards compatibility and to to allow
older hosts to display a meaningful UI even if they don't implement
the new flag yet, all these items MUST be set.
as to the location of the actual enum of labels: fons adriaensen
suggests adding them to the end of the PortNames array.
this implies that for multiple enum-labelled controls, the labels
would have to be concatenated and the host would have to tell them
apart by keeping track of the corresponding UpperBound offsets, which
might become a little messy. your comments are welcome.
best,
jörn
Lennart Poettering wrote:
> What I am saying is that the current system is too "binary": Either
> you have RT sched and then for *everything*. Or you haven't, and then
> you haven't got it for *anything*.
But isn't this more to do with the missing userspace support infrastructure
that numerous people have pointed to than RTPRIO itself? RTPRIO itself does
not imply this "all or nothing" restriction since it *can* be set on a
per-application basis (given appropriate support in userspace for doing so).
I also had a problem with the way PAM did the "all or nothing" approach and
so I wrote set_rlimits - which grants user-specified RT privileges via
RTPRIO on a user/group/program-specific basis. It's not perfect (one has to
start applications via set_rlimits - eg: "set_rlimits ardour") but it works
for me and didn't take all that long to write. Given this I'm sure others
could come up with a workable RTPRIO-based system which included a nice
user-friendly GUI configuration applet (and so forth) - set_rlimits is a
proof-of-concept in a way which shows that something like this can be done.
I mention this because from where I stand on the periphery it seems to me
that the major issues with RTPRIO could well have been solved if the
related userspace support infrastructure had been written.
> For the desktop case you need something in between: RT that cannot be
> misused, basically. Doing that securely is particularly hard ...
Almost anything involving elevated privileges can and will be abused in
time. That's why the action requires elevated privileges in the first
place.
Regards
jonathan
Hi,
first of all thank you for your hard work on developing advanced musical tools for ubuntu.
I just installed Jack2 (1.9.2) because i wanted to test it. Everything was ok when compiling and installing, but when i try to run Jackd, i get this error:
jackd: symbol lookup error: jackd: undefined symbol: jackctl_server_create
I'm sending you log of entire process:
./waf configure --dbus --enable-pkg-config-dbus-service-dir
Linux detected
Checking for program g++ : ok /usr/bin/g++
Checking for compiler version : ok 4.3.3
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for g++ : ok
Checking for program gcc : ok /usr/bin/gcc
Checking for compiler version : ok 4.3.3
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for header samplerate.h : ok
Checking for alsa >= 1.0.0 : ok
Checking for libfreebob >= 1.0.0 : Package "libfreebob (>= 1.0.0)" could not be found or the found version is too old.
Checking for libffado >= 1.999.17 : Package "libffado (>= 1.999.17)" could not be found or the found version is too old.
Checking for dbus-1 >= 1.0.0 : ok
Checking for dbus-1 flags : ok
Checking for header expat.h : ok
Checking for header sndfile.h : ok
Checking for header ncurses.h : ok
Checking for library readline : ok
==================
JACK 1.9.2 exported from r3454M
Build with a maximum of 64 JACK clients
Build with a maximum of 1024 ports
Install prefix : /usr/local
Library directory : /usr/local/lib/
Drivers directory : /usr/local/lib/jack
Build doxygen documentation : no
Build with engine profiling : no
Build with ALSA support : yes
Build with FireWire (FreeBob) support : no
Build with FireWire (FFADO) support : no
Build D-Bus JACK (jackdbus) : yes
D-Bus service install directory : /usr/share/dbus-1/services
Configuration finished successfully (00:00:00); project is now ready to build.
.
sudo ./waf install
[sudo] password for marco:
* installing common/jack/systemdeps.h as /usr/local/include/jack/systemdeps.h
* installing common/jack/jslist.h as /usr/local/include/jack/jslist.h
* installing common/jack/control.h as /usr/local/include/jack/control.h
* symlink /usr/local/bin/jack_disconnect (-> jack_connect)
* installing example-clients/jack_control as /usr/local/bin/jack_control
* installing build/default/jack.pc as /usr/local/lib//pkgconfig/jack.pc
* installing build/default/dbus/org.jackaudio.service as /usr/share/dbus-1/services/org.jackaudio.service
* installing build/default/common/libjackserver.so as /usr/local/lib//libjackserver.so.0.1.0
* symlink /usr/local/lib//libjackserver.so.0 (-> libjackserver.so.0.1.0)
* symlink /usr/local/lib//libjackserver.so (-> libjackserver.so.0.1.0)
* installing build/default/common/libjack.so as /usr/local/lib//libjack.so.0.1.0
* symlink /usr/local/lib//libjack.so.0 (-> libjack.so.0.1.0)
* symlink /usr/local/lib//libjack.so (-> libjack.so.0.1.0)
* installing build/default/common/netmanager.so as /usr/local/lib/jack/netmanager.so
* installing build/default/common/profiler.so as /usr/local/lib/jack/profiler.so
* installing build/default/common/netadapter.so as /usr/local/lib/jack/netadapter.so
* installing build/default/common/audioadapter.so as /usr/local/lib/jack/audioadapter.so
* installing build/default/linux/jackd as /usr/local/bin/jackd
* installing build/default/linux/jack_dummy.so as /usr/local/lib/jack/jack_dummy.so
* installing build/default/linux/jack_alsa.so as /usr/local/lib/jack/jack_alsa.so
* installing build/default/linux/jack_net.so as /usr/local/lib/jack/jack_net.so
* installing build/default/example-clients/jack_load as /usr/local/bin/jack_load
* installing build/default/example-clients/jack_freewheel as /usr/local/bin/jack_freewheel
* installing build/default/example-clients/jack_simple_client as /usr/local/bin/jack_simple_client
* installing build/default/example-clients/jack_showtime as /usr/local/bin/jack_showtime
* installing build/default/example-clients/jack_cpu_load as /usr/local/bin/jack_cpu_load
* installing build/default/example-clients/jack_metro as /usr/local/bin/jack_metro
* installing build/default/example-clients/jack_evmon as /usr/local/bin/jack_evmon
* installing build/default/example-clients/jack_midiseq as /usr/local/bin/jack_midiseq
* installing build/default/example-clients/jack_zombie as /usr/local/bin/jack_zombie
* installing build/default/example-clients/jack_connect as /usr/local/bin/jack_connect
* installing build/default/example-clients/jack_monitor_client as /usr/local/bin/jack_monitor_client
* installing build/default/example-clients/jack_bufsize as /usr/local/bin/jack_bufsize
* installing build/default/example-clients/jack_lsp as /usr/local/bin/jack_lsp
* installing build/default/example-clients/jack_alias as /usr/local/bin/jack_alias
* installing build/default/example-clients/jack_thru as /usr/local/bin/jack_thru
* installing build/default/example-clients/jack_midisine as /usr/local/bin/jack_midisine
* installing build/default/example-clients/jack_unload as /usr/local/bin/jack_unload
* installing build/default/example-clients/jack_server_control as /usr/local/bin/jack_server_control
* installing build/default/tests/jack_test as /usr/local/bin/jack_test
* installing build/default/tests/jack_cpu as /usr/local/bin/jack_cpu
* installing build/default/tests/jack_delay as /usr/local/bin/jack_delay
* installing build/default/tests/jack_multiple_metro as /usr/local/bin/jack_multiple_metro
* installing build/default/example-clients/jack_rec as /usr/local/bin/jack_rec
* installing build/default/example-clients/inprocess.so as /usr/local/lib/jack/inprocess.so
* installing build/default/dbus/jackdbus as /usr/local/bin/jackdbus
Compilation and installation finished successfully (00:00:00)
Thank you very much guys; i'm new to development and understanding of Linux Audio and i will make my best to help the community.
Cheers,
Marco
Hi Nedko,
Looks cool :)
Just add a "visible" toggle button for each curve, should be fairly easy in your python based ui.
Cheers,
J.
--- On Sun, 6/21/09, Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de> wrote:
> From: Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>
> Subject: Re: [LAD] [ANN] lv2fil version 2.0 "New hope" released
> To: "Paul Davis" <paul(a)linuxaudiosystems.com>
> Cc: "Nedko Arnaudov" <nedko(a)arnaudov.name>, linux-audio-dev(a)lists.linuxaudio.org, linux-audio-user(a)lists.linuxaudio.org
> Date: Sunday, June 21, 2009, 6:09 PM
> Paul Davis wrote:
> > 2009/6/20 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>:
> >> Nedko Arnaudov wrote:
> >>> It is not that clean, but I can clean it more
> if such cleanup is
> >>> required for incusion in ardour 2.x.
> >> i don't know if this is still in time for 2.8.1,
> but yes, i would
> >> welcome this patch to go into the queue for
> 2.0-svn.
> >>
> >> haven't got a chance to test it yet (had some
> spurious ardour problems
> >> that i need to pinpoint before adding an
> out-of-tree patch), but hope to
> >> do so today.
> >
> > it has a few issues. not real showstoppers. sampo is
> "on the case",
> > whatever that might mean.
>
> great, thanks. a spiffy-looking equalizer could be a nice
> marketing
> advantage for ardour :-D
>
> while we're at it, we should really have an award for
> plugin spiffiness
> - so far, nedko and the calf team are hot bets. haven't
> checked the
> invada stuff yet, but it also looks very promising indeed.
>
> best,
>
> jörn
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
Hi Nedko,
Looks cool. I would like to try it out.
Where's the ardour patch ? Thanks :)
J.
--- On Sat, 6/13/09, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
> From: Nedko Arnaudov <nedko(a)arnaudov.name>
> Subject: [LAD] [ANN] lv2fil version 2.0 "New hope" released
> To: linux-audio-announce(a)lists.linuxaudio.org, linux-audio-dev(a)lists.linuxaudio.org, linux-audio-user(a)lists.linuxaudio.org
> Date: Saturday, June 13, 2009, 10:40 AM
> Four-band parametric equaliser LV2
> plugin. DSP code by Fons Adriaensen.
>
> Homepage: http://nedko.arnaudov.name/soft/lv2fil/
>
> Screenshot: http://nedko.arnaudov.name/soft/lv2fil/lv2fil.png
>
> Tarball download:
> http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2
> http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2.sig
>
> = Overview =
> Stereo and mono LV2 plugins, four-band parametric
> equalisers.
> Each section has an active/bypass switch, frequency,
> bandwidth and
> gain controls. There is also a global bypass switch and
> gain control.
>
> = DSP =
> The 2nd order resonant filters are implemented using a
> Mitra-Regalia
> style lattice filter, which has the nice property of being
> stable
> even while parameters are being changed.
>
> All switches and controls are internally smoothed, so they
> can be
> used 'live' whithout any clicks or zipper noises. This
> should make
> this plugin a good candidate for use in systems that allow
> automation
> of plugin control ports, such as Ardour, or for stage use.
>
> = GUI =
> The GUI provides knobs and toggle buttons for tweaking
> filter
> parameters. It also provides frequency response widget
> with
> differently coloured curve for each section and separate
> curve for
> total equalization effect.
>
> The GUI uses the External UI extension. lv2rack (part of
> zynjacku)
> supports this extension. Ardour-2.8 needs patch to support
> the
> external UI extension.
>
> --
> Nedko Arnaudov <GnuPG KeyID: DE1716B0>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
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 the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
best,
jörn
Le 15 juin 09 à 01:14, Lennart Poettering a écrit :
> Hmm,
>
> I was just thinking, when jack2 finished initialization it takes a
> name on the session bus, right?
Not sure about what you mean by " it takes name on the session bus". I
hope Nedko can answer better here.
What is implemented right now is the acquire/release scheme based on
your reserver.h,c code. This is done in the ALSA backend.
>
> If that's the case then I could hack up a little module in PA that
> will autoload the JACK connectivity modules as soon as jack becomes
> available. That way we could make the integration between PA and JACK
> a bit closer. Together with the device reservation logic we already
> have in place we could then have out-of-the-box user experience that
> would work like this:
>
> As soon as jack starts up and takes posession of the device, the hw
> device will appear grayed out in pa's volume control, however a new
> virtual device for connectivity with jack appears in the vc. Data
> written to that device will be passed to JACK on a couple of
> ports. It's then up to the user if he wants to make use of those ports
> and connect them inside of jack or just leave them unconnected. (as
> far as I understood the mere existance of a port when it is
> unconnected has no detrimental effect on jack latency behaviour, does
> it?). As soon as JACK terminates the virtual JACK device in PA will go
> away again, and the hw device won't be greyed out anymore.
>
> That way the seperation line between PA clients and JACK clients would
> be blurred a bit.
>
> One could even go a step further and reroute all existing streams from
> the hw device to the virtual jack device, as long as it exists and
> back afterwards. That way starting up jack would have the effect that
> PA's own ALSA backend would simply be temporarily be replaced by
> JACK.
>
> Does that make sense to you?
>
> Lennart
Technically it "could" make sense, but I'm not sure JACK users want
that as the default behaviour. I would prefer if "real users" in JACK
and LAD communities could elaborate on that.
Stephane
Hi,
I knew close to nothing about python but chose waf for the build environment of a project. Depending on how comfortable you are with learning prog. languages, this is not really difficult. And there are tons of examples to get inspired.
I would recommend waf as the project I set up with it is building nicely.
> There are lots of alternatives, including:
>
> * waf -- If you know the Python
> programming language,
> this may be a good
> choice. I've heard good things
> about waf.
>
Ardour3 switched to waf by the way. Jack2 uses waf as well (was a great source of inspiration for my introduction to waf).
J.