Re: [LAD] wfs streaming project report
On Sun, Jan 18, 2009 at 01:00:06PM +0100, Jörn Nettingsmeier wrote: ... therefore, we can safely rule out eye damage to birds as well, unless they are very skilled flyers, very bored and very very stupid. Or just amusing themselves. The European parliamemt building in Brussels has a large surface of shiny glass roofs, and the local birds are amusing them- selves by picking up e.g. small pieces of stone and then dropping them from high altitiude on the roof. They seem to enjoy either the sound it makes, or the line patterns in the broken glass... Earlier today in Rome there was a performance of Stockhausen's Helicopter Quartet (the third ever worldwide) in which the four members of a string quartet perform in as many helicopter hovering above the concert hall, with the resulting music being reproduced for the audience inside. I've not seen any engineering reports on it so far, but it must have been a nice challenge as well. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia O tu, che porte, correndo si ? E guerra e morte ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] wfs streaming project report
Fons Adriaensen wrote: On Sun, Jan 18, 2009 at 01:00:06PM +0100, Jörn Nettingsmeier wrote: Earlier today in Rome there was a performance of Stockhausen's Helicopter Quartet (the third ever worldwide) in which the four members of a string quartet perform in as many helicopter hovering above the concert hall, with the resulting music being reproduced for the audience inside. I've not seen any engineering reports on it so far, but it must have been a nice challenge as well. wow. somebody finally did it? i know there have been at least two attempts before, and both were cancelled as the expenses were skyrocketing :) the tricky part of the heli quartet is that not only do you need 4 bi-directional wireless audio links (the quality of which is pretty secondary, given the available s/n inside a helicopter - i guess you could do it with standard uhf audio gear and pimped antennae), but you also need 4 very high quality video links for the musicians to be shown on screens in the auditorium. and i would imagine a helicopter cockpit to be a quite emr-unfriendly environment, and the available power to be rather noisy... even greater than the engineering challenge will be the challenge of getting anybody to pay for that bs^H^Hthe realisation of such a visionary piece of art. which seems to have succeeded :) flamebaitwhile i do have a soft spot for the old geezer from sirius, i think the money would have been better spent on a whole bunch of other works less heavy on artistic hubris and a bit better equipped in the taste department./flamebait jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] wfs streaming project report
On Sun, Jan 18, 2009 at 02:22:02PM +0100, Jörn Nettingsmeier wrote: even greater than the engineering challenge will be the challenge of getting anybody to pay for that bs^H^Hthe realisation of such a visionary piece of art. which seems to have succeeded :) (from and interview on Radio 3 with the director of Rome's Parco della Musica): Stockhausen visited the Parco della Musica not very long before he died, and on seeing the place (designed by Renzo Piano), mentioned to the director it would be an excellent location for the Helicopter Quartet. The director somehow felt morally obliged to get this organised... The event was part of the Science Festival going on at the location. flamebaitwhile i do have a soft spot for the old geezer from sirius, i think the money would have been better spent on a whole bunch of other works less heavy on artistic hubris and a bit better equipped in the taste department./flamebait We had quite some Stockhausen the past months - I remember at least Hymnen and Stimmung being broadcast live recently. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia O tu, che porte, correndo si ? E guerra e morte ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Saving plugin presets
So far no one has. Just a small excerpt of discussions I remember reading or participating in, In chronological order: http://lalists.stanford.edu/lad/2002/05/0420.html http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-January/006293.html http://lists.linuxaudio.org/pipermail/linux-audio-dev/2006-September/016810.html I even entertained the idea of using sqlite and made some tests once, go figure. Everyone can advocate a format and there are compelling arguments for every single one of them. The difficulty lies in convincing other developers with different views and priorities to adopt yours. Good luck with that! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Saving plugin presets
I don't really think there is a good answer to the format question. What matters is whether there is a simple code-level solution to save presets and to reload them. if there is, it doesn't matter what the format is. ardour has been using turtle (RDF-related) for years because that was assessed early in LADSPA's life as the best choice for a variety of reasons. but it really doesn't matter since we have functions to saverestore presets and we don't care what is inside the preset files. the real problem is there is no library associated with either LADSPA or LV2 and so there is nowhere obvious to put this kind of code. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Saving plugin presets
For the format, let me suggest JSON. i like JSON too, except the lack of first-class URIs yo can map the key names to RDF predicate URIs trivially as well. personally i just use absolute URIs for the keys, since JSON has no namespace mechanism if you want JSON with a namespace mechanism and first class URIs, you might want to check out turtle, which tada, LV2 already uses. from your email i assume youre unaware of this? in this case... and the plugins could store data (wav files, etc.. ) in its subfolders ... LV2 uses a bundle 'folder'. im not sure i think /usr/lib/lv/blahblah.lv2 is the right place for samples. /usr/share/lv2/blahblah.lv2 maybe at which point you have 2 'bundles'.. one bundle for each app-specific FHS location? that sounds wrong to me, and is the opposite of the idea of a bundle a FSHy subdir inside the bundle dir (inside /usr/lib) ? i hate that even more.. We could setup a draft at: http://wiki.linuxaudio.org/wiki/audiofx_plugin_format_draft 404 i presume ..and gather suggestions for parameter names, options, and groups there. lv2 already has this stuff -- Emanuel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Saving plugin presets
To be utterly pragmatic, I think at this moment the best approach for this problem would be an evolutionary one. Just implement whatever format you feel like and see if it takes. No one is going to sue you, although you are guaranteed to get your fair share of critics, no matter what. At the worst case, this particular situation is so utterly simple that it should be trivial to convert one format to another if the need arises. If it helps in the end I chose for my project INI files just because it was a Qt app and Qt provides a nifty INI parser (QSettings) with some merging capabilities (concurrent Qt processes can make changes without corrupting the file and those are easily synchronized.) But that was me just being lazy, I guess. As for the directory structure it went something like: Global: /usr/share/ladspa/presets/plugin-name/preset-name.ini Local: ~/.ladspa/presets/plugin-name/preset-name.ini It is a ladspa-centric app, so it seemed appropriate. I don't recall now if ladspa's can be versioned, but it should be easy to insert a version number somewhere (in the path, in the ini file...) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] wfs streaming project report
Hi Joern, On Sunday 18 January 2009 07:00:06 you wrote: nescivi wrote: On Wednesday 14 January 2009 12:54:12 Jörn Nettingsmeier wrote: http://stackingdwarves.net/public_stuff/event_documentation/wfs_live_tra nsm ission_2008/WFS-Report-web.pdf wow! the paper did not mention this, but did you have any packet losses through birds? or bird losses through packets? very rarely we did indeed have packet losses across the laser link, but since they were so few and far between (even in bad weather), i don't have reliable data. one possible weakness in the whole scheme is that the UDP redundancy methods of both jacktrip and netjack will send redundant packets right next to each other, so that if you have a burst failure (which is common), you are screwed. ok. Not so much a bird city, Cologne, I guess ;) and not the trecking season... so probably there were not so many bird swarms gathering to head south. for me, the morale is: lasers can be made reliable enough if you can tolerate the occasional single or short burst packet loss (loss rates of about 0.0001%), the general internet cannot, unless you get end-to-end QoS, but you can sneak past that if you have lots more bandwidth than you are going to need. but nothing in the world short of http streaming will protect your ass against crappy border gateways and switches that barf on udp stream traffic. as to bird losses, the class 3 lasers operated at 8mW, so the chance of a bird being vaporised is, ahem, slim. the main issue with respect to laser safety was eye damage. the minimum safe distance to look directly into the laser was about 50m. but since IR lasers do not trigger a lid-closing reflex (you only see a dim red shimmer), this minimum safe distance is determined for a duration of 100s of continuously staring into the lens (for lasers in the visible range, this duration is below 1s, iirc). so you would actually have to hover in front of the laser for well over a minute before your retina takes serious damage. therefore, we can safely rule out eye damage to birds as well, unless they are very skilled flyers, very bored and very very stupid. What the visible range of birds? Maybe they could see the beam? Just curious... Thanks for the elaborate answer :) sincerely, Marije ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
