Linux-audio-dev January 2004

linux-audio-dev@lists.linuxaudio.org

94 participants
90 discussions

Re: [linux-audio-dev] [RFC] Lite OSC API

by rd＠alphalink.com.au

> OK, interesting - it wouldn't be a huge task, but why is this a good idea? > It just seems inconvienient for the recipient and I dont know of any other > RPC mechanisms where its allowed (or wanted). In the case of typetag-less > messages it would be difficult to handle, you'd have to try to discover > the type of the argument by inspection. Do you have a link to a rationale > for this? Firstly, from the horses mouth, "non-type-tagged messages [are] totally deprecated". See <http://www.create.ucsb.edu/pipermail/osc_dev/2003-November/00032 9.html> and surrounding posts. I don't think you need to even try to think about possibly considering perhaps partially supporting such things! Secondly, it is actually no work for the receiver. The receiver says that is needs a signed 32bit integer and it gets such an integer. It is a little work for the library. On the other hand it can be a lot of work for the sender. Domain specific languages often do not implement full C like numerical towers, a signal processing language could easily only implement floating point numbers, Lua famously has only double precision floating point numbers, and lots of people use Lua. Since I think this is really important I will give an example, and from the other end of a continuum. I use scheme for most of my music work. Scheme has a very sophisticated numerical tower. I might write (-> "/n_set" 1001 "freq" 440) to set the frequency of an instrument at SC3. The OSC encoder encodes values based on their lisp type, 1001 is an integer and gets encoded as 'i'. Lets assume that to the receiver the frequency argument is a float, here I lose because 440 is an integer. I argue that a receiver implemented like that is just wrong, that an integer 440 frequency is completely valid, and SC3 thankfully agrees and plays the right note. However if you disagree and say that I should write the literal as a float then that makes scheme a hopeless language to work in, 440.0 is still an exact integer, I need to write #i440 to get an inexact integer. But the situation is far worse, if I write (* m 1.5) this seems like it should make an inexact value regardless where m arrives from, however scheme knows that (* 0 1.5) is an exact zero and I lose again, it may even know that (* 2 1.5) == (* 2 3/2) == 3, an exact integer . Forcing a user to _very_ carefully annotate _all_ code that might get sent as an OSC packet _only because_ the OSC receiver cannot accept exact integers is not going to work, I just won't be able to work with the process. SC3 gets this very right, as usual, and in fact allows: (-> "/n_set" #i1000 (exact->inexact 0) 440) The node and index values at SC3 are syntactically integers (the index can also be a string name that maps to an integer), and the argument is syntactically a float, but it accepts floating point encodings of integers and integer encodings of real values. SC3 does it like this, QED :) > I agree that combining the verb and subject seems a little odd, but that > is the sitatuion in the web services world too - when neccesary they get > round it by adding a verb argument eg ("/my/path", "verb", ...), which is > a useful cnvention but its not neccesary to set it in stone. I think the real question is, does anyone really want to do pattern matching on the operator? I have never seen a convincing example. It would introduce all sorts of really strange sequencing issues to start with... The pattern matching people seem to like is usually of the form ("/instr[1-4]/freq" 440), not ("/instr1/{freq,ampl}" 330). If you restrict the matching to the subject, make the subject an argument, and make the operator the OSC address then the OSC dispatch mechanism can be reasonably efficient, which matters in RT synthesis environments, and people who want RE descriptors for subjects can do that without imposing an onerous burden on the core dispatch mechanism. And it looks better! In fact it looks comfortingly like lisp, ("/freq" "/instr[1-4]" 550) :-\ > > * not allocate any memory or call any other non-RT safe procedure > This one is inherantly not possible, youre doing i/o operations. Well actually it is only doing the byte encoding. SC3, being dragged out for yet another example, allows users to link in the synthesis engine and push OSC packets directly onto a queue, thus avoiding any IPC operations but still using an identical communication protocol. For the liblo case you are of course correct, but the temporal behaviour of the encoder/decoder can be pretty predictable. > I've always been more of a strongly-typed guy :) Me too, we schemers all are, we just think that an exact integer is a real number :) Regards, Rohan

20 years, 2 months

[linux-audio-dev] jackit-devel mailing list

by ian esten

anyone got any idea what is wrong with it? i just got a notice from lists.sf.net postmaster saying my message to it could not be delivered and was delayed for an unknown reason... ian

20 years, 2 months

[linux-audio-dev] [RFC] Lite OSC API

by Steve Harris

Hi *, I've been working on a lightweigth OSC API for the last couple of days and I'd appreiciate some comments - it works as it is, but it needs some work and the API isn't final so please dont integrate it into any projects yet. Its quite limited: * only basic OSC types (int, float, string, blob), but adding more is easy * no unix-domain sockets (just UDP) * no bundles * only accepts typed messages (unless you handle the packet parsing yourself) On the upside you can send an OSC message in 2 lines of C using a fprintf style function and you can setup a serverthread with polymorhism/automatic typechecking and callbacks (JACK stylee) very easily. You can also use bits of the API selectivly if you want to mange bits of the OSC lifecycle yourself, eg. handle raw OSC by hand or provide your own thread. Theres an example program that uses it here: http://plugin.org.uk/liblo/liblo/src/testlo.c and you can get the tarball here: http://plugin.org.uk/liblo/ Comments on the API style, testing and offers of help greatfully received. - Steve

20 years, 2 months

[linux-audio-dev] job posting

by Ben

GLW (makers of Harrison high-end consoles) is looking for a senior programmer. Here's the "official" post: Pro Audio company needs senior programmer responsible for system architecture, development environment, code management and related issues. Applicant must demonstrate a broad knowledge of programming languages, tools and multithreading. Linux, BeOS, Windows, Mac OSX, OpenGL, embedded systems, device drivers and pro audio experience is a plus. We are looking for a top-notch programmer. I think there are quite a few developers on this list that should be interested in this job. Send resumes to jobs(a)glw.com. -Ben Loftis

20 years, 2 months

[linux-audio-dev] call for mirrors [was Re: 2nd LAD conference]

by Joern Nettingsmeier

On Thu, 22 Jan 2004, Matthias Nagorni wrote: > On Thu, 22 Jan 2004, Mark Constable wrote: > > > Are there plans to record any of the lectures and put them > > on the web somewhere ? > > Yes, we plan to record the lectures and put also the presentation material > on the web. Moreover we plan to establish a live audio streaming of the > talks and concerts. If we get the presentation material in time, we might > even put that on the web in a way that "remote" listeners can follow the > talks watching the same slides as the audience. > Last time, Steve and J�rn took care of the internet "broadcasting" of the > event. IIRC they also established an IRC channel for "remote" discussion. > The audio quality of the streaming is not a matter of the microphone alone > but more of the available bandwidth. i'm willing to take care of the streaming like last year. this time, i'll try to provide a webcam as well, but i'm not yet sure about streaming video. but a picture every 15 secs or so should be possible. ;) my plan is to have an ogg stream of the talks and the concerts, an irc talkback channel, a website with the presentation material for download and a crude webcam to give you an idea which slide the presenter is talking about atm. work to set up a relay network for streaming will begin by the end of february, i've got a couple other things to do atm. [call for mirrors] if you have a host with good internet connection and are willing to donate some bandwidth, please contact me off-list. either you provide an icecast2 server yourself, or else i will need shell access to build one (though not root). the distribution needs to be recent, or else building icecast2 is problematic. for the webcam, we'll need a couple http servers as well. i thought about round-robin dns, but a friend just pointed out a master server with some php code that will produce a different link each time it is called is probably easier. so all you have to do is pull an image every couple seconds, make it available somewhere and send me the url. yours, joern

20 years, 2 months

[linux-audio-dev] alsa mixer apps

by Florian Schmidt

Hi, i heard on the #alsa irc channel, that some graphical mixer apps don't treat the alsa mixer [ctl] devices not right. For example on a cs46xx alsamixergui does not allow toggling capture on the "Capture" channel. This would be required and is no problem with alsamixergui. I wonder if other mixers have problems like this. This can be confusing like Hell to newbies.. -- http://www.soundclick.com/bands/9/florianschmidt.htm http://www.arted.biz/mista.tapas

20 years, 2 months

[linux-audio-dev] Project: modular synth editor

by Juhana Sadeharju

Hello. I feel we should write a modular synth editor from scratch. I have checked many existing systems but none is good enough. The editor would just be the editor. There would not be anything related to audio processing. Developers could use the editor in any project, audio or not. The editor would handle GUIs such as in AlsaModularSynth, Arts, Galan, Gdam, Glame, NMEdit, PD, Quasimodo, SpiralSynthModular. Also we should have an API and a script in the system. I can set up a project folder to our ftp site, ftp.funet.fi, for resources (manuals and screenshots of existing systems, research papers). Coding should happen in some CVS site. Any comments? Regards, Juhana

20 years, 2 months

Re: [linux-audio-dev] Re: linuxaudio.org

by iriXx

> It should become another LAD event where the linux audio developers > present their work(such as ZKM LAD conference, LinuxTag LAD booth). > > comments? > > Marek yes. there are people /other/ than linux audio developers who will be on the stand at Sounds Expo. its not just an audio development forum. > I propose the following - on sounds expo we should promote LAD and > oss, linux audio projects such as: > > (in no particular order) > > *Ardour *ALSA *Jack *JAMin *LADSPA+swh-plugins *LinuxSampler > *Lilypond etc > > Linux audio distros such as AGNULA, dyne:bolic etc i believe Daniel is planning the event.... m~ -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. --Benjamin Franklin |\ _,,,---,,_ ZZZzz /,`.-'`' -. ;-;;,_ HTTP 503: Too Busy |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) fL .::. www.iriXx.org .::. www.copyleftmedia.org.uk .::.

20 years, 2 months

[linux-audio-dev] ANN: Specimen Version 0.0.3 Released

by Pete Bessman

Guess what? ...*chirp*...*chirp*... Right, well... Specimen is midi controlled audio sampler for GNU/Linux systems, and this is a new release of it. I'm justifying this on the inclusion of velocity sensitivity, cuts, and proof-of-concept (read: crappy) pitch scaling. You can download the newest tarball, check out the new screenshot, and listen to the _fearsome_might_ of Specimen at www.gazuga.net. [pb]

20 years, 2 months

[linux-audio-dev] oprofile, redhat and CONFIG_PREEMPT

by Michael Ost

Hi, all. We want to run oprofile on our redhat 8 based system. It looks like great technology, but an oprofile FAQ says it doesn't work on redhat 8 systems. The FAQ recommends downloading a redhat's oprofile rpm, which we did. But that is configured not to work with a CONFIG_PREEMPT kernel. Our kernel is CONFIG_PREEMPT patched for increased audio performance. Yikes! Has anyone run in to this problem and found a clever solution? An alternate profiler that works? Will we get meaningful results if we rebuild the kernel with CONFIG_PREEMPT turned off? Or perhaps we can run it with CONFIG_PREEMPT on and see what happens? Cheers... =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com mo

20 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 January 2004