Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!]

by James Warden

oops, yeah, wrong discussion thread :) I'm a coder too but not at all in linux-audio, although I started designing a few applications (nothing around DSP or linux core system, kernel, etc, this is way beyond my understanding at the moment. FYI, the closest thing to kernel stuff I did lately was patching oss2jack and kfusd so that this rather obsolete tool could run against kernel 2.6.29). But yes, I wanted to bring a user's point of view to the LAD discussion. About the dual boot, I don't know if it's the best solution but it is certainly a compromise. And one that I would not do myself. I tend to build my own PCs from various components for specific tasks. I find this process cheaper and feel I have a better control over its functioning / etc. About KDE, I am not particularly fond of it, it's just an old habit. I could never get used to gnome although it looks like a fine WM as well. I tried other stuff as well but in the end, I always come back to the shell :) OK, I'll stop the OT blabla. J. --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!] > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Wednesday, June 24, 2009, 8:05 AM > I dunno if you're a coder too, but > those words you wrote are the words of a user :). > > By the way I'm a fan of extremes, I like KDE (only with > KWin) ex 3.5.9 and Ion2, but actually I'm running GNOME and > this also has is advantages and disadvantages. > > Do you agree that a dual or multi boot might be the best > solution to fit to all needs? > > I would interpret your mail this way. You didn't blame any > sound server, but you make out for which usage you are fine > with which sound server. Am I wrong? > > The 'palm pre' thread is uncoupled from the origin thread, > that's why I guess it's okay to speak about user needs here, > nobody will disturb any technical expert knowledge > discussion at the original thread. > > By the way, an rt-audio distro like 64 Studio often works > OOB for rt-audio too, not for my hardware, but it is made to > fit to many hardware combinations. > > Thank you for reporting your experiences. > > Cheers, > Ralf > > James Warden wrote: > > Just a small comment, and then I shut up: > > > > the great thing about linux is its flexibility. I have > a few boxes at home doing different things: > > - a multimedia server based on mythtv, NFS and samba > > - a powerful DAW running an RT patched kernel > > - a couple of laptops for AOB (any other business) > > > > For the AOB laptops, it was nice not to do anything > once I installed the distro. Things worked OOB, and that was > it. > > > > For the DAW or multimedia server, that was another > story ... but simply because customized systems require, > well, customization. The all-in-one distro is and I think > will remain a utopia. > > This said, I recently upgraded my DAW to KDE 4.2 (was > 3.5.9 before upgrade) and that automatically installed > pulseaudio. I had already fiddled around with pulseaudio > about a year ago due to my using VirtualBox (another story). > I found pulse's features kinda cool and I quickly understood > it was not meant as a replacement or alternative to > Jack. > > As of today, my DAW has pulseaudio installed. But all > I had to do was: > > - open the KDE system settings - disable ALL sound > stuff I could find > > > > So basically, KDE offered me the possibility to not > interact at all with the sound layer. It was obviously not a > default setting but it was just a few clicks away. > > > > So let me be straight: it should remain like that. > > On average, a user installing e.g. KDE will expect > desktop sounds to work (sound notifications, mp3 players, > DVD playback, what-not). That's not what I want in my DAW at > all but being myself an old linux "power user", I knew that > it would do that (experience with artsd). I mean, how > could the KDE installation possibly know that it was to be > running on a DAW ?! :D I am glad the desktop config > interface allowed me to configure it the way I wanted (no > extra special services in the background, no sound system > other than what I want for my DAW). > > Now, if things were to change (no longer the > possibility to configure e.g. KDE the way I want), I would > definitely feel pissed-off and complain on some mailing > lists. But let's be also clear: pulseaudio is definitely NOT > the worst things that could happen. It works fine on my > laptops, I don't need to do anything about it and that's > what it was intended for: a generic and multifeatured > desktop sound system. But desktops are also used in other > contexts (e.g. DAW) and it would really be wise to keep > desktop components _optional_ (not only sound system but > also visual effects, etc). That's just simple wisdom and i > suggest we keep it that way. The same applies to jack. It is > a highly specialized tool and should remain so. > > > > > > OK, time to disappear from this discussion. > > > > Cheers, > > J. > > > > > > --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > wrote: > > > > > >> From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > >> Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] > Safe real-time on thedesktop by default; Desktop/audio RT > developers, read this!] > >> To: "james morris" <james(a)jwm-art.net> > >> Cc: linux-audio-dev(a)lists.linuxaudio.org > >> Date: Wednesday, June 24, 2009, 6:45 AM > >> james morris wrote: > >> > >>> On 24/6/2009, "Patrick Shirkey" <pshirkey(a)boosthardware.com> > >>> > >> wrote: > >> > >>> > >>>> It would be helpful if things that could > make a > >>>> > >> big impact will > >> > >>>> continued to be discussed within the LAD > >>>> > >> community. However this is a > >> > >>>> difficult situation. No matter if the > discussions > >>>> > >> are starting prior to > >> > >>>> implementation or post implementation the > general > >>>> > >> direction of the > >> > >>>> arguments tend to be quite emotional. > >>>> > >>>> Is it just because audio guys have a bit > more > >>>> > >> artistic temperament than > >> > >>>> most other developers? > >>>> > > >>> I don't think this adds much to what has been > stated > >>> > >> by Fons and others, > >> > >>> but perhaps it explains a little? > >>> > >>> I'm not a hardcore audio developer like most > of the > >>> > >> guys here, but I've > >> > >>> been making audio/music/noise, and coding, > since the > >>> > >> days of 486sx25s > >> > >>> and windows 3.1. Back then, and for many years > after, > >>> > >> it was a real > >> > >>> concern to be able to disable as many > irrelevant (to > >>> > >> audio) processes in > >> > >>> the system as possible (as I'm sure you're > aware). > >>> > >>> Now I have a pretty capable system, but when I > want to > >>> > >> run RT audio apps > >> > >>> I still want to disable as many irrelevant > processes > >>> > >> on the system as I > >> > >>> can. > >>> > >>> For this reason I really dislike the big > monolithic > >>> > >> desktop environments. > >> > >>> There are several applications tied into them > (some > >>> > >> serious, plain > >> > >>> useful, or just fun) which I'd love to have > working > >>> > >> but which force me > >> > >>> to install all sorts of software I really > don't want > >>> > >> or need - along > >> > >>> with all sorts of processes running in the > >>> > >> background. > >> > >>> So it feels a bit freedom eroding. The choice > seems to > >>> > >> be between a > >> > >>> system which 'just works' but which wastes > system > >>> > >> resources on things > >> > >>> I don't want, or a system which I have to > spend hours > >>> > >> setting up, > >> > >>> constantly have to deal with the > idiosyncrasies of, > >>> > >> but which is as fast > >> > >>> and powerful as it could be. > >>> > >>> The notions of old, to raise the potential for > system > >>> > >> resources to be > >> > >>> only used for the job at hand (ie audio) are > still > >>> > >> strongly rooted and > >> > >>> people don't like it when they feel their > freedom to > >>> > >> use systems in > >> > >>> this way is threatened by forcing them to > install > >>> > >> software and have > >> > >>> running processes they don't want. > >>> > >>> James. > >>> > >> I guess (if needed) separating rt and > bread-and-butter > >> Linux by having a dual-boot is an acceptable > solution. A user with nearly no > >> knowledge could install a comfortable distro for > the everyday desktop > >> environment and another for real-time usage. Even > if somebody don't > >> have any trouble with his Linux install, he might > wish to have a safe Linux > >> for productions and another Linux to have fun and > fun sometimes > >> means to risk things, you won't risk for a > installation that needs > >> to be stable all the time, that's why a dual-boot > has also an advantage, > >> if there will be a joint venture for distro/ > desktop developers and > >> rt hardliners. I have a bad mobo and for rt e.g. I > need to set > >> irq priority for especially the one port where the > MIDI is connected to. > >> I don't think things like that should be done by > the desktop > >> environment. This seems to be impossible. > >> _______________________________________________ > >> Linux-audio-dev mailing list > >> Linux-audio-dev(a)lists.linuxaudio.org > >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > >> > >> > > > > > > > _______________________________________________ > > Linux-audio-dev mailing list > > Linux-audio-dev(a)lists.linuxaudio.org > > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > > > > > -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j… > "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg > >

16 years

Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!]

by James Warden

Just a small comment, and then I shut up: the great thing about linux is its flexibility. I have a few boxes at home doing different things: - a multimedia server based on mythtv, NFS and samba - a powerful DAW running an RT patched kernel - a couple of laptops for AOB (any other business) For the AOB laptops, it was nice not to do anything once I installed the distro. Things worked OOB, and that was it. For the DAW or multimedia server, that was another story ... but simply because customized systems require, well, customization. The all-in-one distro is and I think will remain a utopia. This said, I recently upgraded my DAW to KDE 4.2 (was 3.5.9 before upgrade) and that automatically installed pulseaudio. I had already fiddled around with pulseaudio about a year ago due to my using VirtualBox (another story). I found pulse's features kinda cool and I quickly understood it was not meant as a replacement or alternative to Jack. As of today, my DAW has pulseaudio installed. But all I had to do was: - open the KDE system settings - disable ALL sound stuff I could find So basically, KDE offered me the possibility to not interact at all with the sound layer. It was obviously not a default setting but it was just a few clicks away. So let me be straight: it should remain like that. On average, a user installing e.g. KDE will expect desktop sounds to work (sound notifications, mp3 players, DVD playback, what-not). That's not what I want in my DAW at all but being myself an old linux "power user", I knew that it would do that (experience with artsd). I mean, how could the KDE installation possibly know that it was to be running on a DAW ?! :D I am glad the desktop config interface allowed me to configure it the way I wanted (no extra special services in the background, no sound system other than what I want for my DAW). Now, if things were to change (no longer the possibility to configure e.g. KDE the way I want), I would definitely feel pissed-off and complain on some mailing lists. But let's be also clear: pulseaudio is definitely NOT the worst things that could happen. It works fine on my laptops, I don't need to do anything about it and that's what it was intended for: a generic and multifeatured desktop sound system. But desktops are also used in other contexts (e.g. DAW) and it would really be wise to keep desktop components _optional_ (not only sound system but also visual effects, etc). That's just simple wisdom and i suggest we keep it that way. The same applies to jack. It is a highly specialized tool and should remain so. OK, time to disappear from this discussion. Cheers, J. --- On Wed, 6/24/09, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> > Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default; Desktop/audio RT developers, read this!] > To: "james morris" <james(a)jwm-art.net> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Wednesday, June 24, 2009, 6:45 AM > james morris wrote: > > On 24/6/2009, "Patrick Shirkey" <pshirkey(a)boosthardware.com> > wrote: > > > > > >> It would be helpful if things that could make a > big impact will > >> continued to be discussed within the LAD > community. However this is a > >> difficult situation. No matter if the discussions > are starting prior to > >> implementation or post implementation the general > direction of the > >> arguments tend to be quite emotional. > >> > >> Is it just because audio guys have a bit more > artistic temperament than > >> most other developers? > >> > > > > I don't think this adds much to what has been stated > by Fons and others, > > but perhaps it explains a little? > > > > I'm not a hardcore audio developer like most of the > guys here, but I've > > been making audio/music/noise, and coding, since the > days of 486sx25s > > and windows 3.1. Back then, and for many years after, > it was a real > > concern to be able to disable as many irrelevant (to > audio) processes in > > the system as possible (as I'm sure you're aware). > > > > Now I have a pretty capable system, but when I want to > run RT audio apps > > I still want to disable as many irrelevant processes > on the system as I > > can. > > > > For this reason I really dislike the big monolithic > desktop environments. > > There are several applications tied into them (some > serious, plain > > useful, or just fun) which I'd love to have working > but which force me > > to install all sorts of software I really don't want > or need - along > > with all sorts of processes running in the > background. > > > > So it feels a bit freedom eroding. The choice seems to > be between a > > system which 'just works' but which wastes system > resources on things > > I don't want, or a system which I have to spend hours > setting up, > > constantly have to deal with the idiosyncrasies of, > but which is as fast > > and powerful as it could be. > > > > The notions of old, to raise the potential for system > resources to be > > only used for the job at hand (ie audio) are still > strongly rooted and > > people don't like it when they feel their freedom to > use systems in > > this way is threatened by forcing them to install > software and have > > running processes they don't want. > > > > James. > > I guess (if needed) separating rt and bread-and-butter > Linux by having a > dual-boot is an acceptable solution. A user with nearly no > knowledge > could install a comfortable distro for the everyday desktop > environment > and another for real-time usage. Even if somebody don't > have any trouble > with his Linux install, he might wish to have a safe Linux > for > productions and another Linux to have fun and fun sometimes > means to > risk things, you won't risk for a installation that needs > to be stable > all the time, that's why a dual-boot has also an advantage, > if there > will be a joint venture for distro/ desktop developers and > rt > hardliners. I have a bad mobo and for rt e.g. I need to set > irq priority > for especially the one port where the MIDI is connected to. > I don't > think things like that should be done by the desktop > environment. This > seems to be impossible. > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

16 years

Plugin group Boolean-oriented from lv2 rdf spec?

by Ulrich Lorenz Schlüter

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

16 years

[RFC] LADSPA 1.2

by Jörn Nettingsmeier

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

16 years

Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

by Jonathan Woithe

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

16 years

Autotools and missing headers.

by Ulrich Lorenz Schlüter

Hello, I try to develop some Autotools scripts for my project and I'm getting following make/compile errors: In file included from and.cpp:1: /usr/include/lv2plugin.hpp:34:25: error: lv2_uri_map.h: No such file or directory /usr/include/lv2plugin.hpp:35:29: error: lv2_saverestore.h: No such file or directory /usr/include/lv2plugin.hpp:36:23: error: lv2_event.h: No such file or directory /usr/include/lv2plugin.hpp:37:26: error: lv2_contexts.h: No such file or directory /usr/include/lv2plugin.hpp:38:24: error: lv2types.hpp: No such file or directory configure.ac: # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PREREQ([2.63]) AC_INIT([uli-plugins], [0.1], [audio-mobster(a)gmx.de]) AC_COPYRIGHT([Copyright (C) 2009 by Ulrich-Lorenz Schlüter GPL-3]) AC_CONFIG_SRCDIR([config.h.in]) AC_CONFIG_HEADERS([config.h]) # Version 1.7 of automake is recommended AM_INIT_AUTOMAKE([1.7]) # Checks for programs. AC_PROG_CXX AC_PROG_AWK AC_PROG_CC AC_PROG_CPP AC_PROG_INSTALL AC_PROG_MAKE_SET AC_PROG_LIBTOOL AC_PROG_RANLIB # Checks for libraries. AC_CHECK_LIB([m], [floor], , [AC_MSG_ERROR(Can't find libm)]) PKG_CHECK_MODULES(LV2CORE, lv2core, ,[AC_MSG_ERROR(Can't find liblv2core)]) PKG_CHECK_MODULES(LV2_PLUGIN, lv2-plugin, ,[AC_MSG_ERROR(Can't find liblv2-plugin)]) # Checks for header files. AC_CHECK_HEADERS([lv2.h], , [AC_MSG_ERROR(Can't find lv2.h)]) #AC_CHECK_HEADERS([lv2plugin.hpp], , [AC_MSG_ERROR(Can't find lv2plugin.hpp)]) # Checks for typedefs, structures, and compiler characteristics. AC_HEADER_STDBOOL AC_TYPE_UINT32_T # Checks for library functions. AC_CONFIG_FILES([Makefile delay/Makefile logic/Makefile]) AC_OUTPUT Makefile.am topdir: SUBDIRS = logic delay AUTOMAKE_OPTIONS = foreign AM_CFLAGS = @LV2CORE_CFLAGS@ @LV2_PLUGIN_CFLAGS@ AM_LDFLAGS = @LV2CORE_LIBS@ @LV2_PLUGIN_LIBS@ EXTRA_DIST = autogen.sh Makefile.am from logic: plugindir = $(libdir)/lv2/uli-logic.lv2 plugin_LTLIBRARIES = liband.la libnand.la libor.la libnor.la libxor.la libxnor.la #include_HEADERS = lv2plugin.hpp liband_la_SOURCES = and.cpp libnand_la_SOURCES = nand.cpp libor_la_SOURCES = or.cpp libnor_la_SOURCES = nor.cpp libxor_la_SOURCES = xor.cpp libxnor_la_SOURCES = xnor.cpp Please help my poor soul I'm already desperately crying. :'( Regards Uli

16 years

Jack2 Issue

by Marco Castorina

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

16 years

Re: [LAD] [ANN] lv2fil version 2.0 "New hope" released

by James Warden

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 >

16 years

Re: [LAD] [ANN] lv2fil version 2.0 "New hope" released

by James Warden

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 >

16 years

LADSPA extension for periodic control values?

by Jörn Nettingsmeier

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

16 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev