From S.W.Harris at ecs.soton.ac.uk Mon May 1 05:33:45 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 05:34:06 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146436745.7674.4.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <987c7570eedcce4d6a7a6b8bbe62bd40@jps.net> <1146412765.3531.15.camel@DaveLap> <20060430194935.GB1592@login.ecs.soton.ac.uk> <1146436745.7674.4.camel@DaveLap> Message-ID: <20060501093345.GA13961@login.ecs.soton.ac.uk> On Sun, Apr 30, 2006 at 06:39:05 -0400, Dave Robillard wrote: > > > > Dave, you complain about people talking down about modular > > > > synths, then yourself discount things that are only useful in > > > > non-modular designs? How about a little reciprocity here? > > > [snip] > > > > > > ... a simple "I need it" would have been fine. ;) > > > > On the contrary, some people have said "I need it" to the LOG hint, but > > it's still not the right thing ;) > > That doesn't change the fact that we need it... There's a difference between needing the feature, and needing that part of the spec, which was the point I was trying to make. Logarithmic input values are very important, I couldn't agree more, but the LOG hint doesn't give you that. > Since you took it away, Steve, you'll be the one to define that nice > extension for us, right? :] Sure. - Steve From S.W.Harris at ecs.soton.ac.uk Mon May 1 05:39:58 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 05:40:15 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146442381.8629.26.camel@localhost> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> Message-ID: <20060501093958.GB13961@login.ecs.soton.ac.uk> On Mon, May 01, 2006 at 02:13:00AM +0200, Lars Luthman wrote: > > > > 2) the dynamic program lists and midi mappings (static definitions > > > > could be written in the RDF file, but that's no fun) > > > > > > That's a tougher one. > > > > Control port :| > > Not really - plugins only get to write to the control ports in the run() > callback (or select_program() for DSSIs), and it's entirely possible and > plausible that a program would want to list the available programs for a > plugin before it starts running it's audio callback. I as thinking the host could call run(0), but I guess it might not want to activate either. > Would it be possible to change the instantiation function from > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, > unsigned long SampleRate, > const char* BundlePath, > const char** HostFeatures); > > to something like this: > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, > unsigned long SampleRate, > const char* BundlePath, > const char** HostFeatures, > void** HostFeatureData); > > where HostFeatureData is a NULL-terminated array of the same size as > HostFeatures, containing feature-specific data that the plugin can read > and/or write. Then, if HostFeatures[3] is "PROGRAM_LIST_CALLBACK", > HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor > *(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback > pointer, and the plugin can set it to point to its program list > callback. Or you could define a "DSSI" host feature and a struct similar > to the current DSSI_Descriptor with configure(), get_programs(), > get_midi_controller_for_port() etc and pass a pointer to that instead. It's possible, but it looks a bit ugly to me, and theres no way to update it without calling instantiate again. > I don't see any other obvious way to let future extensions add their own > callbacks (except for specifying a function name in the RDF file and > then dlsym()ing that symbol name in the host). Or passing function poionters over control outs, but thats even nastier. But if its a required host feature, then the mini-spec for the feature can just say what the callback must be called. - Steve From S.W.Harris at ecs.soton.ac.uk Mon May 1 05:42:00 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 05:42:16 2006 Subject: [linux-audio-dev] LADSPA Repository In-Reply-To: <44553EFC.1010507@gjcp.net> References: <4447E144.3000900@boosthardware.com> <1145562498.8827.15.camel@localhost> <1145603686.4773.5.camel@localhost.localdomain> <44553EFC.1010507@gjcp.net> Message-ID: <20060501094200.GC13961@login.ecs.soton.ac.uk> On Sun, Apr 30, 2006 at 11:49:32PM +0100, Gordonjcp wrote: > Jan Weil wrote: > >Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman: > >>How about a machine-friendly interface for searching and downloading > >>plugin tarballs (or references to distribution packages) so one could > >>write a tool like CPAN for LADSPAs? An automated way to download and > >>install plugins would be really useful if it could be integrated into > >>software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new > >>Om patch that you downloaded from the net, you get the message "You > >>don't have the 'foo' plugin, do you want to install it?", click Yes, and > >>a few seconds (or minutes) later the plugin is installed and the patch > >>is loaded. > > > >AFAIK most plugins don't have any dependencies. Is there anything wrong > > DSSI ones may do. It depends what toolkit their GUI was written in. Sorry, I missed the earlier message, but many plugins also link to FFTW, and I wouldn't be supprised to find some that link to DSP libraries. - Steve From ce at christeck.de Mon May 1 12:16:44 2006 From: ce at christeck.de (Christoph Eckert) Date: Mon May 1 12:15:24 2006 Subject: [linux-audio-dev] LAC2006 Photos Message-ID: <200605011816.44731.ce@christeck.de> Hi all, I just uploaded some Photos taken during LAC 2006. It one huge tgz archive, no web gallery available. It will be up in 15 minutes: http://christeck.de/stuff/LAC2006.tar.gz To save bandwidth, I scaled them down a bit. If anyone is interested in a particular high resolution image, don't hesitate to send me an e-mail. Any further resources? Best regards ce From drobilla at connect.carleton.ca Mon May 1 13:51:55 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon May 1 13:52:32 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146442381.8629.26.camel@localhost> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> Message-ID: <1146505915.9746.13.camel@DaveLap> On Mon, 2006-05-01 at 02:13 +0200, Lars Luthman wrote: > On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote: > > On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote: > > > > With the port types specified in the RDF file, MIDI input should be > > > > doable with explicit LADSPA2 ports of some defined MIDI type, which > > > > means that we wouldn't need the run_synth() callback. The GUI > > > > specification and the OSC protocol is already pretty much applicable to > > > > LADSPA as well as DSSI, so that should work in LADSPA2 too. New > > > > additions like MIDI output and transport info could also be done as port > > > > types. > > > > > > > > The things that aren't obvious how to do are > > > > > > > > 1) the configure() callback > > > > > > OSC message. > > > > Thats a little laconic, even by my standards :) To my mind the key thing > > about configure() is that it happens outside the RT context, and > > LADSPA-style plugins have no easy way of running an OSC server of thier > > own. > > > > > > 2) the dynamic program lists and midi mappings (static definitions > > > > could be written in the RDF file, but that's no fun) > > > > > > That's a tougher one. > > > > Control port :| > > Not really - plugins only get to write to the control ports in the run() > callback (or select_program() for DSSIs), and it's entirely possible and > plausible that a program would want to list the available programs for a > plugin before it starts running it's audio callback. > > Would it be possible to change the instantiation function from > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, > unsigned long SampleRate, > const char* BundlePath, > const char** HostFeatures); > > to something like this: > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, > unsigned long SampleRate, > const char* BundlePath, > const char** HostFeatures, > void** HostFeatureData); Eeeww. I like the hostfeatures idea, but don't do parallel arrays, make a struct: struct HostFeature { char* name; void* data; } Though I don't think this is the right way of going about this. We should leave HostFeatures as is and add instantiation parameters (as a few people have requested) with the above form. You could define a HostFeatures that guarantees a certain parameter will be there to get what you want. Something like: struct LADSPA_Parameter { char* name; char* data; } LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor, unsigned long sample_rate, const char* bundle_path, const char** host_features, const LADSPA_Parameter** parameters) Basically the same as Lars' proposal above, slightly remixed to make it more general and useful. This is needed, among other things, for eg. variable number of ports support (through a special port type), which is an extension I would REALLY like to be possible (one plugin, stereo/mono support). Things like FFT bin size, MIDI buffer size, etc. could also be parameters. There's heaps of possible uses.. Semantics: the parameters should be completely optional, and the plugin MUST NOT fail to instantiate based on the lack of a necessary parameter (unless that is specified as a HostFeatures). It could also be used to passs function pointers to the plugin as Lars suggested, which would be very nice, but given what happens if something gets messed up (SEGFAULT), I don't know if this is the best mechanism to provide that. (This isn't really a 'new feature' so much as HostFeatures done right IMO) Thoughts? -DR- From S.W.Harris at ecs.soton.ac.uk Mon May 1 16:24:59 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 16:25:17 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146505915.9746.13.camel@DaveLap> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> Message-ID: <20060501202459.GB28107@login.ecs.soton.ac.uk> On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote: > struct LADSPA_Parameter { > char* name; > char* data; > } > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor, > unsigned long sample_rate, > const char* bundle_path, > const char** host_features, > const LADSPA_Parameter** parameters) > > > Basically the same as Lars' proposal above, slightly remixed to make it > more general and useful. > > This is needed, among other things, for eg. variable number of ports > support (through a special port type), which is an extension I would > REALLY like to be possible (one plugin, stereo/mono support). Things > like FFT bin size, MIDI buffer size, etc. could also be parameters. > There's heaps of possible uses.. IMHO, thats not the way to do any of those things: mono/stereo is best done with dosconnected ports IMHO. That way you can change the connected state and have the plugin react. FFT bin size should be a parameter of the FFT data, for the same reason. MIDI buffer size again, and the output buffer size needs to be set by the plugin, it can be done in RF, or with a well-known control out port if it needs to be dynamic. > Semantics: the parameters should be completely optional, and the plugin > MUST NOT fail to instantiate based on the lack of a necessary parameter > (unless that is specified as a HostFeatures). It could also be used to > passs function pointers to the plugin as Lars suggested, which would be > very nice, but given what happens if something gets messed up > (SEGFAULT), I don't know if this is the best mechanism to provide that. Perhaps, but if so, not for the reasons you say. It's only useful for things that mustn't change during one instantiation cycle, there aren't many things like that. - Steve From drobilla at connect.carleton.ca Mon May 1 16:50:13 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon May 1 16:51:06 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060501202459.GB28107@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> Message-ID: <1146516613.11055.9.camel@DaveLap> On Mon, 2006-05-01 at 21:24 +0100, Steve Harris wrote: > On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote: > > struct LADSPA_Parameter { > > char* name; > > char* data; > > } > > > > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor, > > unsigned long sample_rate, > > const char* bundle_path, > > const char** host_features, > > const LADSPA_Parameter** parameters) > > > > > > Basically the same as Lars' proposal above, slightly remixed to make it > > more general and useful. > > > > This is needed, among other things, for eg. variable number of ports > > support (through a special port type), which is an extension I would > > REALLY like to be possible (one plugin, stereo/mono support). Things > > like FFT bin size, MIDI buffer size, etc. could also be parameters. > > There's heaps of possible uses.. > > IMHO, thats not the way to do any of those things: > > mono/stereo is best done with dosconnected ports IMHO. That way you can > change the connected state and have the plugin react. mono/stereo isn't the best example. I'm thinking of things like an n->1 mixer plugin. > FFT bin size should be a parameter of the FFT data, for the same reason. > > MIDI buffer size again, and the output buffer size needs to be set by the > plugin, it can be done in RF, or with a well-known control out port if it > needs to be dynamic. Both true. I was reaching for examples other than the above one. :) > > Semantics: the parameters should be completely optional, and the plugin > > MUST NOT fail to instantiate based on the lack of a necessary parameter > > (unless that is specified as a HostFeatures). It could also be used to > > passs function pointers to the plugin as Lars suggested, which would be > > very nice, but given what happens if something gets messed up > > (SEGFAULT), I don't know if this is the best mechanism to provide that. > > Perhaps, but if so, not for the reasons you say. It's only useful for > things that mustn't change during one instantiation cycle, there aren't > many things like that. Admittedly the variable ports thing is the only use case I can really think of at the moment. I think you're right though, instantiation parameters probably aren't the best way to achieve that, the number of ports could be provided as a field of the struct the same as MIDI buffer sizes. That's probably better and more consistent; though has the same problems with plugin providing the output and being able to allocate the ports (or dictate how many the host allocates) that MIDI output has. I guess the port things aren't a good justification for the creation parameters, you're right. The question, then, is what is the recommended way for the host to provide functions to the plugin? That's what Lars was originally seeking (and solves the above allocation problem as well) -DR- From S.W.Harris at ecs.soton.ac.uk Mon May 1 17:13:39 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 17:14:43 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146516613.11055.9.camel@DaveLap> References: <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> Message-ID: <20060501211339.GC28107@login.ecs.soton.ac.uk> On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: > > IMHO, thats not the way to do any of those things: > > > > mono/stereo is best done with dosconnected ports IMHO. That way you can > > change the connected state and have the plugin react. > > mono/stereo isn't the best example. I'm thinking of things like an n->1 > mixer plugin. I'd like to not even think about cases like that, it's conceptually quite complex, and there aren't many examples of when it's needed. Like you said below it can be done with complex control ports for example. That's not great either, but for the small number of cases it's needed it doesn't bother me personally. Adding complex features to make certain corner cases easier is what ruins most APIs IMHO. > I guess the port things aren't a good justification for the creation > parameters, you're right. The question, then, is what is the > recommended way for the host to provide functions to the plugin? That's > what Lars was originally seeking (and solves the above allocation > problem as well) I think that if it's provided as part of a HostFeature (so the plugin knows it exists and what it's called) it can be obtained using the OS's normal dynamic linking functions. I've not tried though. - Steve From larsl at users.sourceforge.net Mon May 1 17:24:03 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Mon May 1 17:24:11 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060501211339.GC28107@login.ecs.soton.ac.uk> References: <1146164997.14289.154.camel@localhost> <20060428083135.GG22764@login.ecs.soton.ac.uk> <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> Message-ID: <1146518643.8846.15.camel@localhost> On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: > > I guess the port things aren't a good justification for the creation > > parameters, you're right. The question, then, is what is the > > recommended way for the host to provide functions to the plugin? That's > > what Lars was originally seeking (and solves the above allocation > > problem as well) > > I think that if it's provided as part of a HostFeature (so the plugin > knows it exists and what it's called) it can be obtained using the OS's > normal dynamic linking functions. I've not tried though. Do you mean that the plugin should dlopen the host? Wouldn't that require some way to pass the path to the host program to the plugin (in which case you might as well pass a function pointer directly)? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060501/abd19015/attachment.bin From S.W.Harris at ecs.soton.ac.uk Mon May 1 17:27:56 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 1 17:28:14 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146518643.8846.15.camel@localhost> References: <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> Message-ID: <20060501212756.GD28107@login.ecs.soton.ac.uk> On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: > On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: > > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: > > > I guess the port things aren't a good justification for the creation > > > parameters, you're right. The question, then, is what is the > > > recommended way for the host to provide functions to the plugin? That's > > > what Lars was originally seeking (and solves the above allocation > > > problem as well) > > > > I think that if it's provided as part of a HostFeature (so the plugin > > knows it exists and what it's called) it can be obtained using the OS's > > normal dynamic linking functions. I've not tried though. > > Do you mean that the plugin should dlopen the host? Wouldn't that > require some way to pass the path to the host program to the plugin (in > which case you might as well pass a function pointer directly)? I mean the linker should do it. If you dynamically build the plugin against a stub library and the host exports something with the same ABI, I /think/ the plugin should have the host's version of the function in its namespace. - Steve From larsl at users.sourceforge.net Mon May 1 17:33:40 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Mon May 1 17:33:45 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060501212756.GD28107@login.ecs.soton.ac.uk> References: <200604291509.49790.cannam@all-day-breakfast.com> <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> Message-ID: <1146519220.8846.17.camel@localhost> On Mon, 2006-05-01 at 22:27 +0100, Steve Harris wrote: > On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: > > On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: > > > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: > > > > I guess the port things aren't a good justification for the creation > > > > parameters, you're right. The question, then, is what is the > > > > recommended way for the host to provide functions to the plugin? That's > > > > what Lars was originally seeking (and solves the above allocation > > > > problem as well) > > > > > > I think that if it's provided as part of a HostFeature (so the plugin > > > knows it exists and what it's called) it can be obtained using the OS's > > > normal dynamic linking functions. I've not tried though. > > > > Do you mean that the plugin should dlopen the host? Wouldn't that > > require some way to pass the path to the host program to the plugin (in > > which case you might as well pass a function pointer directly)? > > I mean the linker should do it. If you dynamically build the plugin > against a stub library and the host exports something with the same ABI, I > /think/ the plugin should have the host's version of the function in its > namespace. Can't that cause all sorts of memory protection errors on systems that do not support backlinking? On the other hand, if it works on Linux that is good enough for me. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060501/b8e899c8/attachment.bin From S.W.Harris at ecs.soton.ac.uk Tue May 2 05:07:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 05:08:10 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1146519220.8846.17.camel@localhost> References: <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <1146519220.8846.17.camel@localhost> Message-ID: <20060502090747.GA7472@login.ecs.soton.ac.uk> On Mon, May 01, 2006 at 11:33:40PM +0200, Lars Luthman wrote: > > I mean the linker should do it. If you dynamically build the plugin > > against a stub library and the host exports something with the same ABI, I > > /think/ the plugin should have the host's version of the function in its > > namespace. > > Can't that cause all sorts of memory protection errors on systems that > do not support backlinking? On the other hand, if it works on Linux that > is good enough for me. No idea. If you care then look into it (I'm not even sure its possible), there are ways to get function pointers into plugins though, if you care enough. - Steve From fons.adriaensen at alcatelaleniaspace.com Tue May 2 07:50:31 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Tue May 2 07:50:43 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146002289.3637.1.camel@DaveLap> References: <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> Message-ID: <20060502115031.GA15307@bth05w.ABSp.alcatel.be> On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote: > You are completely missing the entire point of LADSPA2. All the > unecessary data has been removed from the header file (ie the plugin > code). > > Look at the example plugin's code, it will be painfully obvious what the > advantage is. A lot of plugins create what is essentially a block of constants by dynamically allocating and initialising every bit of it. ISTR there was (is) even an 'offical' plugin example source doing it that way. Compared to that the new code is indeed simpler. But it's a braindead way of doing it really, and that makes the comparison totally invalid. I really don't see what is 'complex' or 'difficult' about e.g. static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] = { LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO, LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO, LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO, LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO, LADSPA_PORT_INPUT | LADSPA_PORT_CONTROL, .... }; Further, you can't really remove all of this data. Most of it will be required by the plugin code itself, and you can't expect it to go and read it from the RDF. -- FA Follie! Follie! Delirio vano e' questo! From fons.adriaensen at alcatelaleniaspace.com Tue May 2 11:57:44 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Tue May 2 11:57:54 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060429010004.GC3518@replic.net> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> Message-ID: <20060502155744.GB15307@bth05w.ABSp.alcatel.be> On Sat, Apr 29, 2006 at 01:00:04AM +0000, carmen wrote: > > It's not possible for a host to know how to scale a port from just the unit > > labeling. Unit labeling and input value scaling are independent, in fact > > are completely orthogonal except in certain conventional cases like > > IEC for some (not all!) dB ranges. > > ++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) > vs log(2). im sure this RDF/JSON/YAML thing can make a case for it ++ I can't imagine any sane interface standard for audio controls without a way to say that the natural way to represent a port's range is exponential. That is all the hint does. It does not imply any transformation done by the host on the actual control value, only the way it should map to a widget's range. Ardour gets its defaults wrong for ports with a log hint, but that's no reason to drop them. The reason why it gets them wrong is probably because the code handling defaults is something like 10 times more complicated than it need be. -- FA Follie! Follie! Delirio vano e' questo! From paul at linuxaudiosystems.com Tue May 2 12:15:20 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue May 2 12:11:28 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502155744.GB15307@bth05w.ABSp.alcatel.be> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> Message-ID: <1146586520.4941.61.camel@localhost.localdomain> On Tue, 2006-05-02 at 17:57 +0200, Alfons Adriaensen wrote: > I can't imagine any sane interface standard for audio controls without a > way to say that the natural way to represent a port's range is exponential. saying that the port range is exponential doesn't pin it down very much. it still requires the host to make decisions about precisely what kind of exponential curve to use for the range, and it may get it wrong. > Ardour gets its defaults wrong for ports with a log hint, but that's > no reason to drop them. i suggested dropping it because it doesn't appear to me to provide adequate information to use it correctly. i fully support having a way to indicate that a port range is exponential if it includes *all* the required information. > The reason why it gets them wrong is probably > because the code handling defaults is something like 10 times more > complicated than it need be. care to suggest a simpler approach? From S.W.Harris at ecs.soton.ac.uk Tue May 2 12:21:44 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 12:22:06 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <1146586520.4941.61.camel@localhost.localdomain> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> Message-ID: <20060502162144.GD7472@login.ecs.soton.ac.uk> On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis wrote: > On Tue, 2006-05-02 at 17:57 +0200, Alfons Adriaensen wrote: > > I can't imagine any sane interface standard for audio controls without a > > way to say that the natural way to represent a port's range is exponential. > > saying that the port range is exponential doesn't pin it down very much. > it still requires the host to make decisions about precisely what kind > of exponential curve to use for the range, and it may get it wrong. The "type" is irrelevant, the problem is that what I generally want to say is "this goes from 0Hz to fs/2Hz, and I want it to be logarithmic", but you can't say that literally, so you have to say "this goes from fs/10000Hz to fs/2Hz", which tends to make the bottom value a bit random. I don't know what the correct solution is, possibly just providing a rule for the host to caluculate what it should use instead of log(0) is enough, but I'm not sure what the rule should be. > > The reason why it gets them wrong is probably > > because the code handling defaults is something like 10 times more > > complicated than it need be. > > care to suggest a simpler approach? LADSPA defaults are broken, and hopefully not relevant. - Steve From fons.adriaensen at skynet.be Tue May 2 13:19:18 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 2 13:11:51 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <1146586520.4941.61.camel@localhost.localdomain> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> Message-ID: <20060502171918.GA4832@linux-1> On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis wrote: > saying that the port range is exponential doesn't pin it down very much. > it still requires the host to make decisions about precisely what kind > of exponential curve to use for the range, and it may get it wrong. It does pin it down completely. Given the endpoint values there is only one exponential curve, and it's simple enough to compute in both directions. > care to suggest a simpler approach? Will do, once I catch up... -- FA Follie! Follie! Delirio vano e' questo! From fons.adriaensen at skynet.be Tue May 2 13:21:31 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 2 13:14:03 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502162144.GD7472@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502162144.GD7472@login.ecs.soton.ac.uk> Message-ID: <20060502172131.GB4832@linux-1> On Tue, May 02, 2006 at 05:21:44PM +0100, Steve Harris wrote: > "this goes from 0Hz to fs/2Hz, and I want it to be logarithmic", That's a contradiction. -- FA Follie! Follie! Delirio vano e' questo! From jdboyd at jdboyd.net Tue May 2 14:02:12 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Tue May 2 14:17:22 2006 Subject: [linux-audio-dev] NAB trade show In-Reply-To: <200604201001.32116.ben@glw.com> References: <20060420135738.C542511913FE@music.columbia.edu> <200604201001.32116.ben@glw.com> Message-ID: <20060502180212.GB6583@jdboyd.zill.net> On Thu, Apr 20, 2006 at 10:01:32AM -0500, Ben Loftis wrote: > I am going to be at the NAB show in Las Vegas this week. Any other LAD's > planning to be there? So what did you see? I was there, but I had left by the time you sent this (I was on a set up crew). The only audio gear I really got arround to looking at was some of the gear from Linear Accoustic (but they are broadcast audio, not so much studio audio). One this I've been wondering is how do the 5.1 upmix boxes work? The ones that take in stereo and convert it to surround sound. The sales weenies I talked to sounded like they were making it up. One idea I had was to sum 2 FIRs (one for each source). generated from placing 2 speakers and a surround sound mic setup in a hall. Any free software working on doing this sort of thing. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From indigo at bitglue.com Tue May 2 14:34:20 2006 From: indigo at bitglue.com (Phil Frost) Date: Tue May 2 14:34:30 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060501212756.GD28107@login.ecs.soton.ac.uk> References: <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> Message-ID: <20060502183420.GA12127@unununium.org> On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: > On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: > > Do you mean that the plugin should dlopen the host? Wouldn't that > > require some way to pass the path to the host program to the plugin (in > > which case you might as well pass a function pointer directly)? > > I mean the linker should do it. If you dynamically build the plugin > against a stub library and the host exports something with the same ABI, I > /think/ the plugin should have the host's version of the function in its > namespace. From what I glean from this you are talking about having the plugin .so access symbols that are defined in the host. I know this is possible, and you don't even have to link against any stub library. Check out the -E or --export-dynamic option to gnu ld. I don't know if this is a good idea, though. It feels kinda freaky. From paul at linuxaudiosystems.com Tue May 2 14:47:37 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue May 2 14:43:46 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502171918.GA4832@linux-1> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502171918.GA4832@linux-1> Message-ID: <1146595658.4941.81.camel@localhost.localdomain> On Tue, 2006-05-02 at 19:19 +0200, fons adriaensen wrote: > On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis wrote: > > > saying that the port range is exponential doesn't pin it down very much. > > it still requires the host to make decisions about precisely what kind > > of exponential curve to use for the range, and it may get it wrong. > > It does pin it down completely. Given the endpoint values there is only > one exponential curve, and it's simple enough to compute in both > directions. note: the hint didn't say "exponential". it said "logarithmic". From fons.adriaensen at skynet.be Tue May 2 15:07:47 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 2 15:00:30 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <1146595658.4941.81.camel@localhost.localdomain> References: <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502171918.GA4832@linux-1> <1146595658.4941.81.camel@localhost.localdomain> Message-ID: <20060502190747.GC4832@linux-1> On Tue, May 02, 2006 at 02:47:37PM -0400, Paul Davis wrote: > note: the hint didn't say "exponential". it said "logarithmic". If V represents the value sent to the port, and P the corresponding widget position, it means that the function V -> P should be logarithmic wich is the same as saying that P -> V is exponential. It depends on your P of V which name makes the most sense :-) -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Tue May 2 15:49:59 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 2 15:16:53 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060502115031.GA15307@bth05w.ABSp.alcatel.be> References: <20060424075757.GB22289@login.ecs.soton.ac.uk> <1145883487.2493.126.camel@DaveLap> <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> <20060502115031.GA15307@bth05w.ABSp.alcatel.be> Message-ID: <1146599399.5357.3.camel@DaveLap> On Tue, 2006-05-02 at 13:50 +0200, Alfons Adriaensen wrote: > On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote: > > > > You are completely missing the entire point of LADSPA2. All the > > unecessary data has been removed from the header file (ie the plugin > > code). > > > > Look at the example plugin's code, it will be painfully obvious what the > > advantage is. > > A lot of plugins create what is essentially a block of constants by > dynamically allocating and initialising every bit of it. ISTR there was > (is) even an 'offical' plugin example source doing it that way. > Compared to that the new code is indeed simpler. But it's a braindead > way of doing it really, and that makes the comparison totally invalid. > > I really don't see what is 'complex' or 'difficult' about e.g. > > > static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] = > { > LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO, > LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO, > LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO, > LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO, > LADSPA_PORT_INPUT | LADSPA_PORT_CONTROL, > .... > }; That would be a valid point if all the data that people wanted to associate with plugins was strictly defined right now (which is impossible). That is the whole problem with LADSPA1 that we need to fix here, hence the external data file. > > Further, you can't really remove all of this data. Most of it > will be required by the plugin code itself, and you can't expect > it to go and read it from the RDF. Since the plugin author writes both and they are strongly associated with (and depend on) each other, the plugin can 'assume' eg. the type of it's ports. Plugin code definitely won't be reading the RDF file. -DR- From S.W.Harris at ecs.soton.ac.uk Tue May 2 15:22:55 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 15:23:13 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502190747.GC4832@linux-1> References: <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502171918.GA4832@linux-1> <1146595658.4941.81.camel@localhost.localdomain> <20060502190747.GC4832@linux-1> Message-ID: <20060502192255.GA24654@login.ecs.soton.ac.uk> On Tue, May 02, 2006 at 09:07:47 +0200, fons adriaensen wrote: > On Tue, May 02, 2006 at 02:47:37PM -0400, Paul Davis wrote: > > > note: the hint didn't say "exponential". it said "logarithmic". > > If V represents the value sent to the port, and P the corresponding > widget position, it means that the function V -> P should be logarithmic > wich is the same as saying that P -> V is exponential. > > It depends on your P of V which name makes the most sense :-) Yes, I've always though HINT_EXPONENTIAL would be clearer, but whatever. - Steve From S.W.Harris at ecs.soton.ac.uk Tue May 2 15:28:03 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 15:28:21 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502172131.GB4832@linux-1> References: <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502162144.GD7472@login.ecs.soton.ac.uk> <20060502172131.GB4832@linux-1> Message-ID: <20060502192803.GB24654@login.ecs.soton.ac.uk> On Tue, May 02, 2006 at 07:21:31 +0200, fons adriaensen wrote: > On Tue, May 02, 2006 at 05:21:44PM +0100, Steve Harris wrote: > > > "this goes from 0Hz to fs/2Hz, and I want it to be logarithmic", > > That's a contradiction. Yes, quite, but the only other option is to express it as a fraction of the sample rate, or an absolute value at both ends, neither of which is right. The plugin can handle 0, and the host should be free to choose any value in that range, but I have to set some arbitrary positive limit which is ineviatably unhelpful, and the host has no real choice but to take it literally. - Steve From S.W.Harris at ecs.soton.ac.uk Tue May 2 15:29:55 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 15:30:12 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060502183420.GA12127@unununium.org> References: <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060502183420.GA12127@unununium.org> Message-ID: <20060502192955.GC24654@login.ecs.soton.ac.uk> On Tue, May 02, 2006 at 02:34:20 -0400, Phil Frost wrote: > On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: > > On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: > > > Do you mean that the plugin should dlopen the host? Wouldn't that > > > require some way to pass the path to the host program to the plugin (in > > > which case you might as well pass a function pointer directly)? > > > > I mean the linker should do it. If you dynamically build the plugin > > against a stub library and the host exports something with the same ABI, I > > /think/ the plugin should have the host's version of the function in its > > namespace. > > From what I glean from this you are talking about having the plugin .so > access symbols that are defined in the host. I know this is possible, > and you don't even have to link against any stub library. Check out the > -E or --export-dynamic option to gnu ld. OK, great. Do you know if OSX and Windows have equivalents? > I don't know if this is a good idea, though. It feels kinda freaky. Perhaps, it was just one suggestion for how to achieve that. It's not needed by all plugins, so it doesnt have to be glaringly obvious, it just has to work. And this disucssion is purely hypothetical at this stage anyway. - Steve From S.W.Harris at ecs.soton.ac.uk Tue May 2 15:32:39 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 2 15:33:09 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <1146599399.5357.3.camel@DaveLap> References: <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> <20060502115031.GA15307@bth05w.ABSp.alcatel.be> <1146599399.5357.3.camel@DaveLap> Message-ID: <20060502193238.GD24654@login.ecs.soton.ac.uk> On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote: > > Further, you can't really remove all of this data. Most of it > > will be required by the plugin code itself, and you can't expect > > it to go and read it from the RDF. > > Since the plugin author writes both and they are strongly associated > with (and depend on) each other, the plugin can 'assume' eg. the type of > it's ports. Plugin code definitely won't be reading the RDF file.S I've not yet seen a plugin that introspects its own port hints either, but don't take that as a challenge ;) - Steve From drobilla at connect.carleton.ca Tue May 2 16:16:18 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 2 15:36:36 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502162144.GD7472@login.ecs.soton.ac.uk> References: <20060427084530.GE21744@login.ecs.soton.ac.uk> <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502162144.GD7472@login.ecs.soton.ac.uk> Message-ID: <1146600978.5357.28.camel@DaveLap> On Tue, 2006-05-02 at 17:21 +0100, Steve Harris wrote: > On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis wrote: > > On Tue, 2006-05-02 at 17:57 +0200, Alfons Adriaensen wrote: > > > I can't imagine any sane interface standard for audio controls without a > > > way to say that the natural way to represent a port's range is exponential. > > > > saying that the port range is exponential doesn't pin it down very much. > > it still requires the host to make decisions about precisely what kind > > of exponential curve to use for the range, and it may get it wrong. > > The "type" is irrelevant, the problem is that what I generally want to say > is "this goes from 0Hz to fs/2Hz, and I want it to be logarithmic", but > you can't say that literally, so you have to say "this goes from > fs/10000Hz to fs/2Hz", which tends to make the bottom value a bit random. > > I don't know what the correct solution is, possibly just providing a rule > for the host to caluculate what it should use instead of log(0) is enough, > but I'm not sure what the rule should be. The problem here is that most people who want the log hint just want it as, well.. a logarithmic hint. Not a precise definition of a mathmatical mapping from parameter value to port value (which would also be nice, but is a seperate thing really). As an example, I map MIDI controllers to negative parameter ranges ALL the time, and using an exponential curve more often than not. Obviously in a strict mathmatical sense this doesn't work out at all (can't have a negative log), but it's a useful (necessary for me) feature. (as mentioned I calculate the curve on [1, n] and shift it down to wherever I need it). I would like ladspa:logarithmic to remain as the fuzzy not-very-well-defined hint that it is right now, because it solves the UI/MIDI/etc problems. You can't even provide a usable frequency slider to a user without it! A future extension that precisely defines ranges, units, scales, etc. wouldn't conflict with this simple hint. That said, I'm not going to lose any sleep over it not being in there. The end effect will just be that the extension which fixes it will become a de facto standard. Battles over what metadata to include in the spec is best left until after we have the C side of things absolutely pinned down to everyone's satisfaction, IMO. -DR- -DR- From drobilla at connect.carleton.ca Tue May 2 16:20:58 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 2 15:40:06 2006 Subject: [linux-audio-dev] LADSPA2: logarithmic hint In-Reply-To: <20060502190747.GC4832@linux-1> References: <1146129205.27822.0.camel@DaveLap> <20060427101233.GH21744@login.ecs.soton.ac.uk> <20060428083059.GF22764@login.ecs.soton.ac.uk> <67009e0bef58e93d2f6aec64f5c8ae5a@jps.net> <20060429010004.GC3518@replic.net> <20060502155744.GB15307@bth05w.ABSp.alcatel.be> <1146586520.4941.61.camel@localhost.localdomain> <20060502171918.GA4832@linux-1> <1146595658.4941.81.camel@localhost.localdomain> <20060502190747.GC4832@linux-1> Message-ID: <1146601258.5357.29.camel@DaveLap> On Tue, 2006-05-02 at 21:07 +0200, fons adriaensen wrote: > On Tue, May 02, 2006 at 02:47:37PM -0400, Paul Davis wrote: > > > note: the hint didn't say "exponential". it said "logarithmic". > > If V represents the value sent to the port, and P the corresponding > widget position, it means that the function V -> P should be logarithmic > wich is the same as saying that P -> V is exponential. > > It depends on your P of V which name makes the most sense :-) hehe. +1 clever points :) -DR- From drobilla at connect.carleton.ca Tue May 2 16:34:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 2 15:50:05 2006 Subject: [linux-audio-dev] LADSPA 2 In-Reply-To: <20060502193238.GD24654@login.ecs.soton.ac.uk> References: <20060424145354.GA14607@login.ecs.soton.ac.uk> <958b3a2e0604240921i44e3bd15p3891c8bed248e757@mail.gmail.com> <20060425084646.GG24930@login.ecs.soton.ac.uk> <958b3a2e0604250328j19b53b13rf8f27fbac3f72f6c@mail.gmail.com> <20060425115926.GL24930@login.ecs.soton.ac.uk> <1146002303.14289.27.camel@localhost> <1146002289.3637.1.camel@DaveLap> <20060502115031.GA15307@bth05w.ABSp.alcatel.be> <1146599399.5357.3.camel@DaveLap> <20060502193238.GD24654@login.ecs.soton.ac.uk> Message-ID: <1146602055.5357.43.camel@DaveLap> On Tue, 2006-05-02 at 20:32 +0100, Steve Harris wrote: > On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote: > > > Further, you can't really remove all of this data. Most of it > > > will be required by the plugin code itself, and you can't expect > > > it to go and read it from the RDF. > > > > Since the plugin author writes both and they are strongly associated > > with (and depend on) each other, the plugin can 'assume' eg. the type of > > it's ports. Plugin code definitely won't be reading the RDF file.S > > I've not yet seen a plugin that introspects its own port hints either, but > don't take that as a challenge ;) I suppose it does have a path to it's own bundle, and could theoretically parse manifest.ttl to find it's own data file and do what it wants with it. But.. I mean... just.. no! :) (I did actually consider adding plugin-side hooks to my ladspa2 library but decided against it) -- Speaking of the library, status update: I have successfully processed data with the example plugin in about 5 lines of C code. Plugins can be 'loaded' with one LOC using only the URI (finding and loading the plugin is all automagic), and instantiated with one more LOC. -DR- From ben at glw.com Tue May 2 18:28:36 2006 From: ben at glw.com (Ben Loftis) Date: Tue May 2 18:24:50 2006 Subject: [linux-audio-dev] Re: NAB trade show In-Reply-To: <20060502193015.53E52141D3B5@music.columbia.edu> References: <20060502193015.53E52141D3B5@music.columbia.edu> Message-ID: <200605021728.36402.ben@glw.com> > > So what did you see? > Not much honestly. Digi was demo'ing the new version of PT but they are just playing catchup with the innovative companies at this point. The coolest thing at the show was definitely Ardour, which we were using as a playback and recording machine for our mixing consoles. > One this I've been wondering is how do the 5.1 upmix boxes work? The > ones that take in stereo and convert it to surround sound. The sales There are infinite ways to do this and none of them make the music sound better than stereo. OK I guess "better" is subjective but there's certainly no "correct" way to do it. You can easily derive a center/sub channel but most systems do something hideous when it comes to the rear channels. -Ben Loftis www.harrisonconsoles.com From spikethehobbitmage at excite.com Wed May 3 03:37:27 2006 From: spikethehobbitmage at excite.com (spikethehobbitmage@excite.com) Date: Wed May 3 03:37:34 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard Message-ID: <20060503073727.AC88C8B50D@xprdmxin.myway.com> I have gained much valuable insight from reading the posts from last month on Linux Audio Dev and OpenGraphics. I have tried to incorporate what wisdom I could. Someone wiser than I could greatly improve on this, of course. Hence this document. Low to mid-range markets are saturated. Buildable, but not likely saleable. Top end market is pretty tight. R&D budget for that level of gear is probably more than the video card project. Semi-pro is more doable. Best bet is an aggressive design to sell on performance and features. Most advanced features can be implemented in software, so the hardware should be fairly straight-forward, but it still needs good throughput. Target market Semi-pro audio (high end of target) High end gamers (mid range of target) Home theater (low end of target) Hobbyist -Hobbyist add-ons could greatly increase saleability to other markets US$300? price range for baseline system - this needs to be priced out 19" rackmount boxes may cost more. Mainly due to the sheer volume of good stuff that can be packed into them. see below. Features 192kHz @ 24bit inputs and outputs (48 bit fixed point internal) on board resampling/mixing sample rate bit depth # channels channel swap on board realtime compression/decompression/transcoding all analog I/O is in (shielded) breakout boxes more than one kind of box supported (including custom boxes) more than one box at a time supported breakout boxes may be up to 100m from host system MIDI 5.1 optical ADAT sound samples/effects may be preloaded to card and played/mixed on demand full 3D audio processing custom codecs and effects generators may be loaded on demand on board speech synthesis - just another codec :) on board speech recognition - same :) IR remote control? watchdog timer? Several people have voiced desire for 192kHz capability and have indicated media at this quality is available from some sources. Native sample capabilities 192kHz at 24 bit max - more than this would be overkill, and would hurt other capabilities without benefit 96kHz, 48kHz, 44100Hz, 22050Hz, 11025Hz for good measure -there is no point resampling to a higher rate unless you are going to mix with a higher rate source. digital resampling does not increase sound quality. -resampling from 44100 (CD audio) and lower to 48k or higher creates artifacts (not an even multiple) -more processing power/bandwidth is available for effects/additional channels at lower sample speeds. halving the sample rate doubles the processing power available per sample. 48 bit fixed point internal DSP for best accuracy all samples converted to 48 bit fixed point for internal processing -there should be no data loss from this conversion -if the hardware is efficient: -there should be negligible performance penalty for conversion -there should be no performance penalty for using the higher bit depth -simplified design if all DSP functions and codecs use the same format -downsampling from 48 to 24 bit for output is trivial if implemented in hardware World clock world master capable may also use external world clock -card can repeat clock to host system and breakout boxes if no dedicated world clock wiring is desired or possible, soft world clock may be implemented -ie card and each peripheral generate their own clock and a periodic sync signal is provided over data channel. see below. -unit may not be able to run at full speed due to timing constraints/clock skew in this case. not acceptable for live work, but OK for lower markets. Virtual back plane for maximum flexibility (any input may be mapped to any output with any filtering/effects) external effects box can therefore be patched in at any location, if desired volume controls are 10-12 bit analog inputs sample at 20Hz? volume control sampling does not need to be synchronized to any world clock mutes are 1 bit input arrays. same sampling as above. I/O card is purely digital all analog and most digital I/O is in breakout boxes. see below. Analog inputs and outputs are discrete from each other (no dual I/O jacks to toast a mic with) powered outputs are discrete from line outputs 1/8", 1/4", RCA, balanced XLR as appropriate inputs digitally controlled analog gain or preamp for each channel analog prefilters to reduce digital aliasing digital post filter? (cropping excess digital bits is trivial) outputs digitally controlled output gain or postamp 5th or 7th order Bessel filters standard Digital optical S/PDIF in and out (5.1 audio) ADAT (lightpipe) in and out (8 channel, optical) does anybody have specs on this? how hard is it to get interface hardware? cost? licencing? (this is an open design, so this could be an issue) MIDI CD digital audio in/out (2 channel, 16 bit, 44100, twisted pair) this would be on-card, if provided could be used to link to other cards Breakout Boxes more than one type of box should be supportable 5 1/4" internal/external box? cheapest to build shielded for internal mounting line in/line out/mic/headphone/IR/MIDI 5.1 line out? volume control input may only need 100baseT if bandwidth isn't a problem 9" (approx) external box home theater/gamer 5.1 analog and optical in/out 5.1 analog speaker out (power amp) (5.1 analogs can be configured as 3 stereo pairs, or 6 mono) IR/MIDI/mic/headphone software controlled AM/FM radio tuner? LCD display? digital spectrum analyzer display? 19" rack mount (someone with experience could probably give better layout) I/O patch board 60-80 ports 1/4", balanced XLR (with switchable phantom power), headphone 1-2 volume controls per column ADAT in/out MIDI world clock in/out 1000baseT Control box 8-16 ports 1/4", XLR (with switchable phantom power), headphone ADAT in/out MIDI world clock in/out 32 volume control sliders with mutes (2 banks of 16) 4 master volume sliders with mutes (same as above, just labelled differently?) knob switches? (to select option or backplane presets, etc) 2 16 pos switches could be encoded in a byte or 4 4 pos switches, etc digital spectrum analyzer display? (also a programmable output) -this would suggest an equalizer somewhere would be in order too :) peak/RMS volume readouts? (which they are is a setting) 1000baseT more than one box at a time should be supported master can command boxes to forward streams to each other directly? multi master? ie more than one card connected to a group of breakout boxes and each other more complex design allows cards to talk to each other directly or share I/O resources 1000baseT connection NOT TCP/IP or IPv6 - should NOT be WAN routable don't need the extra overhead somebody is going to want to use the same switch their internet connection goes through.... all analog audio channels are 24 bit volume control channels are 10-12 bit mute controls are bit arrays requires in-box microcontroller as much work as possible should be done in hardware minimal processing requirements due to simple protocol ECC encode/decode/fixup is a large part of workload no DSP capability, other than perhaps hardware filters any digital filtering should be done by Master unit simple remote commands box detection broadcast (true PnP) per channel input signal forwarding (either to output on same box, output on other box, or to Master) world clock mode selection set gain controls box identification manufacturer model serial number(optional) I/O count/descriptions read current settings main load is data stream latch and marshal input signals for transmit (controlled by world clock) unmarshal packets to output signal latches 2 stage latch stepped by world clock lesser load is volume/mute update stream. same profile, just lower bandwidth I/O bandwidth 192kHz at 24bit is 576000 B/s 48kHz at 24bit is 144000 B/s max channels for 24 bit audio 192kHz 48kHz 10baseT 1 6 100baseT 17 69 Firewire 69 277 (400MHz) 1000baseT 173 694 100MHz could barely handle 17 channels @ 192kHz if you add ECC (usually a good idea) it would be even less Firewire can handle up to 69 channels (less for ECC), but protocols/drivers are a mess -how much does firewire hardware cost compared to 1000baseT? how to get? -Firewire2 at 800MHz might be a possibility, but again, cost/availability? Master Unit 1/2 height 1/2 length card PCI or PCIe form factor PCIe should be main focus offers higher bandwidth/lower latency than PCI common on newer machines by the time this gets to market, this will be the dominant standard x1 should be fast enough PCI provided for legacy support large current install base limited lifetime 1000baseT external connector 100 or 1000baseT internal connector (depending on cost and whether the 5 1/4" box needs 1000baseT) world clock in/out (to connect to another card in the same computer) ADAT I/O? 5.1 optical out? RAM 32-64 MB (128?) DDR dual channel? CPU 200MHz minimum can we do 300MHz, or even 400? overclockable with active cooling? 3rd party fan/water cooling mounts dual core? RISC like instruction set 48 bit fixed point DSP instructions or DSP farm 8-32 bit integer math (48 bit integer math?) bitwise functions should be efficient for compression/decompression using various codecs 32 bit address path so memory is upgradeable just by modifying the PCB I/O controls/registers should be separate bus, so memory map is linear minimal onboard boot loader, if required. all software is loaded from host system separate data and instruction L1 caches MMU so codecs run in own memory, don't direct have access to hardware necessary for buggy or untrusted codecs DMA to access host computer memory accelerated task switching multiple register files? OS embedded Linux to start with (at least until design is proofed) a true RTOS would be preferable multi-tasking SMP capable if CPU is dual core zero copy IO for performance will take a while to write :P maybe hack Linux? that is what it is for, after all on board watchdog timer? good if she locks up can be used as host computer watchdog timer as well hardware random # generator? can be used for white noise production 3 profiles of signal handling Live this is usually going from an analog input to an analog output highest priority in processing minimal buffering to reduce delay needs to be < 20ms, even if signal is passed through card more than once eg input -> card -> external effects box -> card -> output) this puts the highest load on the card critical for audiophiles may be important for gamers and hobbyists minimal importance for home theater Real-time this could be recording or playback precise timing is only necessary at source or output, respectively double buffering to improve efficiency is an asset even 500ms delay playing an MP3 doesn't matter. prebuffering several seconds wouldn't hurt anything either. video sync isn't affected if the timing signal back to the computer is generated AFTER the decompression codec output buffer double (or more) buffering during recording is critical to prevent data loss, especially if the audio is being compressed in real time Transcode lowest priority - this could be done entirely using time left over from the other operations buffering to improve efficiency is an must delay, clock skew, etc don't matter could be used with non-audio data with appropriate codecs (SETI at HOME, anyone?) If I have missed or messed up anything, that is just me being me. Please feel free to correct/mock/browbeat as appropriate. :) _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From S.W.Harris at ecs.soton.ac.uk Wed May 3 03:46:06 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 3 03:46:31 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <20060503073727.AC88C8B50D@xprdmxin.myway.com> References: <20060503073727.AC88C8B50D@xprdmxin.myway.com> Message-ID: <20060503074606.GB1956@login.ecs.soton.ac.uk> On Wed, May 03, 2006 at 03:37:27 -0400, spikethehobbitmage@excite.com wrote: > World clock I think you mean Word Clock. > Digital > optical S/PDIF in and out (5.1 audio) > ADAT (lightpipe) in and out (8 channel, optical) > does anybody have specs on this? > how hard is it to get interface hardware? > cost? > licencing? (this is an open design, so this could be an issue) IIRC it's not an open design. It's owned by Alesis. - Steve From S.W.Harris at ecs.soton.ac.uk Wed May 3 06:28:44 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 3 06:29:15 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux Message-ID: <20060503102844.GA4662@login.ecs.soton.ac.uk> Richard's preferred name of "PEA" (AKA anything that's not LADSPA2) got me to thinking. What about abstracting it up one level and calling the directory + .so files + manifest thing a POD (Plugin Object and Description). Theres nothing particularly audio specific about the high level construct, its "just" that we don't have a concrete ABI for dealing with sills, video etc. This means that what we think of as a "LADSPA2" plugin would be a "LADSPA POD". The directory would have a .pod extension. POD seems like a nice word to me, plenty of scope for puns, short and "pod plugin" on google doesn't come up with anything much. The only audio related things for "pod" I could see are: a guitar effects processor called a PODxt (there was a POD historically), an audio I/O device called a Firepod, and the documentation for the LADSPA Perl module. Perl docs are the only non-coincidental hits for "LADSPA POD". I could juggle the description stuff around the seperate pod-ness from ladspa-ness, it's not hard, but also not neccesary. There is a small name clash with Perl, which uses .pod for it's documentation format, but I dont think that's really an issue, our .pods will be found in POD_PATH (eg. /usr/lib/pod/, ~/.pod/) and be will be directories. Thoughts? - Steve From t_w_ at freenet.de Wed May 3 07:34:53 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Wed May 3 07:35:00 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503102844.GA4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> Message-ID: <20060503113453.GA7347@charly.SWORD> On Wed, May 03, 2006 at 11:28:44AM +0100, Steve Harris wrote: > > POD seems like a nice word to me, plenty of scope for puns, short and "pod > plugin" on google doesn't come up with anything much. The only audio > related things for "pod" I could see are: a guitar effects processor called > a PODxt (there was a POD historically), an audio I/O device called a > Firepod, and the documentation for the LADSPA Perl module. Perl docs > are the only non-coincidental hits for "LADSPA POD". > Thoughts? ++ Cheers, Thorsten Wilms From b0ef at esben-stien.name Wed May 3 11:12:12 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed May 3 09:14:15 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <20060503073727.AC88C8B50D@xprdmxin.myway.com> (spikethehobbitmage@excite.com's message of "Wed, 3 May 2006 03:37:27 -0400 (EDT)") References: <20060503073727.AC88C8B50D@xprdmxin.myway.com> Message-ID: <873bfrnnw3.fsf@esben-stien.name> "" writes: > 192kHz Sorry to bring back the 192kHz discussion, but I think you find that no one here seriously wants that or so I understand. It's theoretical infeasible. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From lists at rumori.de Wed May 3 13:37:36 2006 From: lists at rumori.de (martin rumori) Date: Wed May 3 13:36:29 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503102844.GA4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> Message-ID: <20060503173736.GF4346@benfica.tejo> On Wed, May 03, 2006 at 11:28:44AM +0100, Steve Harris wrote: > plugin" on google doesn't come up with anything much. The only audio > related things for "pod" I could see are: a guitar effects processor called not to forget about the POD algorithmic composition programm by canadian composer barry truax back in the 70s, AFAIR he used it for spectrally POisson Distributed audio synthesis. martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060503/9317c492/attachment.bin From S.W.Harris at ecs.soton.ac.uk Wed May 3 13:58:54 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 3 13:59:24 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503173736.GF4346@benfica.tejo> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <20060503173736.GF4346@benfica.tejo> Message-ID: <20060503175854.GC4662@login.ecs.soton.ac.uk> On Wed, May 03, 2006 at 07:37:36PM +0200, martin rumori wrote: > On Wed, May 03, 2006 at 11:28:44AM +0100, Steve Harris wrote: > > plugin" on google doesn't come up with anything much. The only audio > > related things for "pod" I could see are: a guitar effects processor called > > not to forget about the POD algorithmic composition programm by > canadian composer barry truax back in the 70s, AFAIR he used it for > spectrally POisson Distributed audio synthesis. Hmmm, yes. Didn't know about that. It doesnt show up on the first few pages of google results, but it is there. The last mention I can see is in 1999: http://www.sfu.ca/~truax/podwork.html There's bascially a choice between choosing a crap name, and treading on someones toes slightly. It doesn't seem like a LADSPA POD plugin format would steal any thunder from Truax. - Steve From seablaede at gmail.com Wed May 3 14:05:03 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Wed May 3 14:01:32 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503102844.GA4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> Message-ID: <4458F0CF.2060300@gmail.com> > The only audio > related things for "pod" I could see are: a guitar effects processor called > a PODxt (there was a POD historically), an audio I/O device called a > Firepod, and the documentation for the LADSPA Perl module. Perl docs > are the only non-coincidental hits for "LADSPA POD". Pod devices are used in live sound fairly often, probably much more so than guitarists would like;) The basic concept I have absolutely no problem with, nor do I have a problem with the naming of it, I do have to wonder though whether it may be taking things a bit to far, or farther than they need to be though. I just don't really see the need I suppose to create a new name for a package, as that is really about all this would be right? The manifest and code is part of the LADSPA development, and wouldn't really carry over to any other plugin used in this package format correct? Or am I missing the point entirely? Seablade From pshirkey at boosthardware.com Wed May 3 14:24:10 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Wed May 3 14:24:58 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <4458F0CF.2060300@gmail.com> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> Message-ID: <4458F54A.9090105@boosthardware.com> Thomas Vecchione wrote: >> The only audio >> related things for "pod" I could see are: a guitar effects processor >> called >> a PODxt (there was a POD historically), an audio I/O device called a >> Firepod, and the documentation for the LADSPA Perl module. Perl docs >> are the only non-coincidental hits for "LADSPA POD". > > > Pod devices are used in live sound fairly often, probably much more so > than guitarists would like;) > > So theoretically you could find a way to put a .pod on a PODxt. I was trying to think of a name that encapsulated the concept of pluggable bits of code and mod was gone. A .pod is entirely relevant and easily memorable. If it's really available then stake your claim before anyone else does. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From james at dis-dot-dat.net Wed May 3 14:35:26 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed May 3 14:34:30 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <20060503073727.AC88C8B50D@xprdmxin.myway.com> References: <20060503073727.AC88C8B50D@xprdmxin.myway.com> Message-ID: <20060503183526.GJ29248@fitz.Belkin> On Wed, 03 May, 2006 at 03:37AM -0400, spikethehobbitmage@excite.com spake thus: > > I have gained much valuable insight from reading the posts from last month on Linux Audio Dev and OpenGraphics. I have tried to incorporate what wisdom I could. Someone wiser than I could greatly improve on this, of course. Hence this document. When can you send me one? I'm excited and I don't like waiting! :) This all sounds very very good. > > Low to mid-range markets are saturated. Buildable, but not likely saleable. Top end market is pretty tight. R&D budget for that level of gear is probably more than the video card project. Semi-pro is more doable. > > Best bet is an aggressive design to sell on performance and features. Most advanced features can be implemented in software, so the hardware should be fairly straight-forward, but it still needs good throughput. > > Target market > Semi-pro audio (high end of target) > High end gamers (mid range of target) > Home theater (low end of target) > Hobbyist > -Hobbyist add-ons could greatly increase saleability to other markets > US$300? price range for baseline system - this needs to be priced out > 19" rackmount boxes may cost more. Mainly due to the sheer volume of good stuff that can be packed into them. see below. > > > Features > 192kHz @ 24bit inputs and outputs (48 bit fixed point internal) > on board resampling/mixing > sample rate > bit depth > # channels > channel swap > on board realtime compression/decompression/transcoding > all analog I/O is in (shielded) breakout boxes > more than one kind of box supported (including custom boxes) > more than one box at a time supported > breakout boxes may be up to 100m from host system > MIDI > 5.1 optical > ADAT > sound samples/effects may be preloaded to card and played/mixed on demand > full 3D audio processing > custom codecs and effects generators may be loaded on demand > on board speech synthesis - just another codec :) > on board speech recognition - same :) > IR remote control? > watchdog timer? > > > Several people have voiced desire for 192kHz capability and have indicated media at this quality is available from some sources. > > Native sample capabilities > 192kHz at 24 bit max - more than this would be overkill, and would hurt other capabilities without benefit > 96kHz, 48kHz, 44100Hz, 22050Hz, 11025Hz for good measure > -there is no point resampling to a higher rate unless you are going to mix with a higher rate source. digital resampling does not increase sound quality. > -resampling from 44100 (CD audio) and lower to 48k or higher creates artifacts (not an even multiple) > -more processing power/bandwidth is available for effects/additional channels at lower sample speeds. halving the sample rate doubles the processing power available per sample. > 48 bit fixed point internal DSP for best accuracy > all samples converted to 48 bit fixed point for internal processing > -there should be no data loss from this conversion > -if the hardware is efficient: > -there should be negligible performance penalty for conversion > -there should be no performance penalty for using the higher bit depth > -simplified design if all DSP functions and codecs use the same format > -downsampling from 48 to 24 bit for output is trivial if implemented in hardware > > > World clock > world master capable > may also use external world clock > -card can repeat clock to host system and breakout boxes > if no dedicated world clock wiring is desired or possible, soft world clock may be implemented > -ie card and each peripheral generate their own clock and a periodic sync signal is provided over data channel. see below. > -unit may not be able to run at full speed due to timing constraints/clock skew in this case. not acceptable for live work, but OK for lower markets. > > > Virtual back plane for maximum flexibility (any input may be mapped to any output with any filtering/effects) > external effects box can therefore be patched in at any location, if desired > volume controls are 10-12 bit analog inputs > sample at 20Hz? > volume control sampling does not need to be synchronized to any world clock > mutes are 1 bit input arrays. same sampling as above. > > > I/O > card is purely digital > all analog and most digital I/O is in breakout boxes. see below. > > Analog > inputs and outputs are discrete from each other (no dual I/O jacks to toast a mic with) > powered outputs are discrete from line outputs > 1/8", 1/4", RCA, balanced XLR as appropriate > inputs > digitally controlled analog gain or preamp for each channel > analog prefilters to reduce digital aliasing > digital post filter? (cropping excess digital bits is trivial) > outputs > digitally controlled output gain or postamp > 5th or 7th order Bessel filters standard > > Digital > optical S/PDIF in and out (5.1 audio) > ADAT (lightpipe) in and out (8 channel, optical) > does anybody have specs on this? > how hard is it to get interface hardware? > cost? > licencing? (this is an open design, so this could be an issue) > MIDI > CD digital audio in/out (2 channel, 16 bit, 44100, twisted pair) > this would be on-card, if provided > could be used to link to other cards > > > Breakout Boxes > more than one type of box should be supportable > > 5 1/4" internal/external box? > cheapest to build > shielded for internal mounting > line in/line out/mic/headphone/IR/MIDI > 5.1 line out? > volume control input > may only need 100baseT if bandwidth isn't a problem > > 9" (approx) external box > home theater/gamer > 5.1 analog and optical in/out > 5.1 analog speaker out (power amp) > (5.1 analogs can be configured as 3 stereo pairs, or 6 mono) > IR/MIDI/mic/headphone > software controlled AM/FM radio tuner? > LCD display? > digital spectrum analyzer display? > > 19" rack mount (someone with experience could probably give better layout) > > I/O patch board > 60-80 ports > 1/4", balanced XLR (with switchable phantom power), headphone > 1-2 volume controls per column > ADAT in/out > MIDI > world clock in/out > 1000baseT > > Control box > 8-16 ports > 1/4", XLR (with switchable phantom power), headphone > ADAT in/out > MIDI > world clock in/out > 32 volume control sliders with mutes (2 banks of 16) > 4 master volume sliders with mutes (same as above, just labelled differently?) > knob switches? (to select option or backplane presets, etc) > 2 16 pos switches could be encoded in a byte or 4 4 pos switches, etc > digital spectrum analyzer display? (also a programmable output) > -this would suggest an equalizer somewhere would be in order too :) > peak/RMS volume readouts? (which they are is a setting) > 1000baseT > > more than one box at a time should be supported > master can command boxes to forward streams to each other directly? > multi master? > ie more than one card connected to a group of breakout boxes and each other > more complex design > allows cards to talk to each other directly or share I/O resources > 1000baseT connection > NOT TCP/IP or IPv6 - should NOT be WAN routable > don't need the extra overhead > somebody is going to want to use the same switch their internet connection goes through.... > all analog audio channels are 24 bit > volume control channels are 10-12 bit > mute controls are bit arrays > requires in-box microcontroller > as much work as possible should be done in hardware > minimal processing requirements due to simple protocol > ECC encode/decode/fixup is a large part of workload > no DSP capability, other than perhaps hardware filters > any digital filtering should be done by Master unit > simple remote commands > box detection broadcast (true PnP) > per channel input signal forwarding (either to output on same box, output on other box, or to Master) > world clock mode selection > set gain controls > box identification > manufacturer > model > serial number(optional) > I/O count/descriptions > read current settings > main load is data stream > latch and marshal input signals for transmit (controlled by world clock) > unmarshal packets to output signal latches > 2 stage latch stepped by world clock > lesser load is volume/mute update stream. same profile, just lower bandwidth > > > I/O bandwidth > 192kHz at 24bit is 576000 B/s > 48kHz at 24bit is 144000 B/s > > max channels for 24 bit audio > 192kHz 48kHz > 10baseT 1 6 > 100baseT 17 69 > Firewire 69 277 (400MHz) > 1000baseT 173 694 > > 100MHz could barely handle 17 channels @ 192kHz > if you add ECC (usually a good idea) it would be even less > Firewire can handle up to 69 channels (less for ECC), but protocols/drivers are a mess > -how much does firewire hardware cost compared to 1000baseT? how to get? > -Firewire2 at 800MHz might be a possibility, but again, cost/availability? > > > Master Unit > 1/2 height 1/2 length card > PCI or PCIe form factor > PCIe > should be main focus > offers higher bandwidth/lower latency than PCI > common on newer machines > by the time this gets to market, this will be the dominant standard > x1 should be fast enough > PCI > provided for legacy support > large current install base > limited lifetime > 1000baseT external connector > 100 or 1000baseT internal connector (depending on cost and whether the 5 1/4" box needs 1000baseT) > world clock in/out (to connect to another card in the same computer) > ADAT I/O? > 5.1 optical out? > RAM > 32-64 MB (128?) > DDR > dual channel? > CPU > 200MHz minimum > can we do 300MHz, or even 400? > overclockable with active cooling? > 3rd party fan/water cooling mounts > dual core? > RISC like instruction set > 48 bit fixed point DSP instructions or DSP farm > 8-32 bit integer math (48 bit integer math?) > bitwise functions > should be efficient for compression/decompression using various codecs > 32 bit address path so memory is upgradeable just by modifying the PCB > I/O controls/registers should be separate bus, so memory map is linear > minimal onboard boot loader, if required. all software is loaded from host system > separate data and instruction L1 caches > MMU so codecs run in own memory, don't direct have access to hardware > necessary for buggy or untrusted codecs > DMA to access host computer memory > accelerated task switching > multiple register files? > OS > embedded Linux to start with (at least until design is proofed) > a true RTOS would be preferable > multi-tasking > SMP capable if CPU is dual core > zero copy IO for performance > will take a while to write :P > maybe hack Linux? that is what it is for, after all > on board watchdog timer? > good if she locks up > can be used as host computer watchdog timer as well > hardware random # generator? > can be used for white noise production > > > 3 profiles of signal handling > Live > this is usually going from an analog input to an analog output > highest priority in processing > minimal buffering to reduce delay > needs to be < 20ms, even if signal is passed through card more than once > eg input -> card -> external effects box -> card -> output) > this puts the highest load on the card > critical for audiophiles > may be important for gamers and hobbyists > minimal importance for home theater > Real-time > this could be recording or playback > precise timing is only necessary at source or output, respectively > double buffering to improve efficiency is an asset > even 500ms delay playing an MP3 doesn't matter. prebuffering several seconds wouldn't hurt anything either. > video sync isn't affected if the timing signal back to the computer is generated AFTER the decompression codec output buffer > double (or more) buffering during recording is critical to prevent data loss, especially if the audio is being compressed in real time > Transcode > lowest priority - this could be done entirely using time left over from the other operations > buffering to improve efficiency is an must > delay, clock skew, etc don't matter > could be used with non-audio data with appropriate codecs (SETI at HOME, anyone?) > > > If I have missed or messed up anything, that is just me being me. Please feel free to correct/mock/browbeat as appropriate. :) > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > > From klaus.kosten at gmx.de Wed May 3 13:20:05 2006 From: klaus.kosten at gmx.de (Klaus Kosten) Date: Wed May 3 15:20:20 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <4458F54A.9090105@boosthardware.com> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> Message-ID: <4458E645.5060906@gmx.de> Patrick Shirkey schrieb: > Thomas Vecchione wrote: > >>> The only audio >>> related things for "pod" I could see are: a guitar effects processor >>> called >>> a PODxt (there was a POD historically), an audio I/O device called a >>> Firepod, and the documentation for the LADSPA Perl module. Perl docs >>> are the only non-coincidental hits for "LADSPA POD". >> >> >> >> Pod devices are used in live sound fairly often, probably much more so >> than guitarists would like;) >> >> > > So theoretically you could find a way to put a .pod on a PODxt. > > I was trying to think of a name that encapsulated the concept of > pluggable bits of code and mod was gone. A .pod is entirely relevant and > easily memorable. > > If it's really available then stake your claim before anyone else does. > Before further discussing the name "Pod", please have a look at www.line6.com/products/pods/ . There is a whole family of FX processors for guitar and bass under the registered trademark "POD", and these devices are well known and widely used. So it?s probably not a good idea to name a software effects collection "Pod". Just my 2 EURO-cents. Klaus -- From seablaede at gmail.com Wed May 3 15:30:25 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Wed May 3 15:26:53 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <4458E645.5060906@gmx.de> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> Message-ID: <445904D1.3060106@gmail.com> > > Before further discussing the name "Pod", please have a look at www.line6.com/products/pods/ . There is a whole family of FX processors for guitar and bass under the registered trademark "POD", and these devices are well known and widely used. So it?s probably not a good idea to name a software Yep these are the majority of what I was referring to actually;) Seablade From indigo at bitglue.com Wed May 3 15:33:31 2006 From: indigo at bitglue.com (Phil Frost) Date: Wed May 3 15:34:13 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503175854.GC4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <20060503173736.GF4346@benfica.tejo> <20060503175854.GC4662@login.ecs.soton.ac.uk> Message-ID: <20060503193331.GA26003@unununium.org> On Wed, May 03, 2006 at 06:58:54PM +0100, Steve Harris wrote: > There's bascially a choice between choosing a crap name, and treading on > someones toes slightly. It doesn't seem like a LADSPA POD plugin format > would steal any thunder from Truax. *cough* or, pick a name that is longer than 3 letters. From S.W.Harris at ecs.soton.ac.uk Wed May 3 15:56:10 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 3 15:56:49 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503193331.GA26003@unununium.org> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <20060503173736.GF4346@benfica.tejo> <20060503175854.GC4662@login.ecs.soton.ac.uk> <20060503193331.GA26003@unununium.org> Message-ID: <20060503195610.GD4662@login.ecs.soton.ac.uk> On Wed, May 03, 2006 at 03:33:31PM -0400, Phil Frost wrote: > On Wed, May 03, 2006 at 06:58:54PM +0100, Steve Harris wrote: > > There's bascially a choice between choosing a crap name, and treading on > > someones toes slightly. It doesn't seem like a LADSPA POD plugin format > > would steal any thunder from Truax. > > *cough* or, pick a name that is longer than 3 letters. length(name) > 3 == crap in my book. - Steve From S.W.Harris at ecs.soton.ac.uk Wed May 3 16:13:18 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 3 16:14:30 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060503195610.GD4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <20060503173736.GF4346@benfica.tejo> <20060503175854.GC4662@login.ecs.soton.ac.uk> <20060503193331.GA26003@unununium.org> <20060503195610.GD4662@login.ecs.soton.ac.uk> Message-ID: <20060503201318.GE4662@login.ecs.soton.ac.uk> On Wed, May 03, 2006 at 08:56:10PM +0100, Steve Harris wrote: > On Wed, May 03, 2006 at 03:33:31PM -0400, Phil Frost wrote: > > On Wed, May 03, 2006 at 06:58:54PM +0100, Steve Harris wrote: > > > There's bascially a choice between choosing a crap name, and treading on > > > someones toes slightly. It doesn't seem like a LADSPA POD plugin format > > > would steal any thunder from Truax. > > > > *cough* or, pick a name that is longer than 3 letters. > > length(name) > 3 == crap in my book. Hmm... maybe > 4, but short is definatly good. - Steve From julien at c-lab.de Wed May 3 17:38:35 2006 From: julien at c-lab.de (Julien Claassen) Date: Wed May 3 17:38:48 2006 Subject: [linux-audio-dev] first ladspa2 example? Message-ID: Hi everyone! I think, I heard, that someone already did some preliminary example for ladspa2. Am I right there? If so, where can I find it? Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From spikethehobbitmage at excite.com Wed May 3 19:22:42 2006 From: spikethehobbitmage at excite.com (spikethehobbitmage@excite.com) Date: Wed May 3 19:22:49 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard Message-ID: <20060503232242.E62168B373@xprdmxin.myway.com> Steve, > I think you mean Word Clock. you are probably right. > IIRC it's not an open design. It's owned by Alesis. That may or may not be a problem depending on their licencing requirments. Esben, No need to be sorry :) If 192kHz is to high we can always slow it down. 96 or 48 would allow more processing power to be used for other things. James, I want one too :) _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From drobilla at connect.carleton.ca Wed May 3 21:36:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed May 3 21:36:30 2006 Subject: [linux-audio-dev] first ladspa2 example? In-Reply-To: References: Message-ID: <1146706574.22500.2.camel@DaveLap> On Wed, 2006-05-03 at 23:38 +0200, Julien Claassen wrote: > Hi everyone! > I think, I heard, that someone already did some preliminary example for > ladspa2. Am I right there? If so, where can I find it? > Kindest regards > Julien The provisional header and an example plugin from Steve Harris is at: http://plugin.org.uk/ladspa2/ Note that EVERYTHING found there is provisional and VERY subject to change. I do have a partially completed host library and a working host using it, but that won't be released until the spec is finalized (or goes in to a "beta" stage at least) -DR- From drobilla at connect.carleton.ca Wed May 3 21:38:28 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed May 3 21:38:44 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <4458E645.5060906@gmx.de> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> Message-ID: <1146706709.22500.5.camel@DaveLap> On Wed, 2006-05-03 at 19:20 +0200, Klaus Kosten wrote: > Patrick Shirkey schrieb: > > Thomas Vecchione wrote: > > > >>> The only audio > >>> related things for "pod" I could see are: a guitar effects processor > >>> called > >>> a PODxt (there was a POD historically), an audio I/O device called a > >>> Firepod, and the documentation for the LADSPA Perl module. Perl docs > >>> are the only non-coincidental hits for "LADSPA POD". > >> > >> > >> > >> Pod devices are used in live sound fairly often, probably much more so > >> than guitarists would like;) > >> > >> > > > > So theoretically you could find a way to put a .pod on a PODxt. > > > > I was trying to think of a name that encapsulated the concept of > > pluggable bits of code and mod was gone. A .pod is entirely relevant and > > easily memorable. > > > > If it's really available then stake your claim before anyone else does. > > > > Before further discussing the name "Pod", please have a look at > www.line6.com/products/pods/ . There is a whole family of FX processors > for guitar and bass under the registered trademark "POD", and these > devices are well known and widely used. So it?s probably not a good idea > to name a software effects collection "Pod". This is a good point. The POD line is _VERY_ well known, and given that plugins can be effects or guitar amp models etc (ie the domain is similar) I wouldn't be surprised if Line6's lawyers had something to say about it once they find out. -DR- From pshirkey at boosthardware.com Wed May 3 21:57:54 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Wed May 3 21:58:22 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <1146706709.22500.5.camel@DaveLap> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> Message-ID: <44595FA2.7090807@boosthardware.com> Dave Robillard wrote: > > This is a good point. The POD line is _VERY_ well known, and given that > plugins can be effects or guitar amp models etc (ie the domain is > similar) I wouldn't be surprised if Line6's lawyers had something to say > about it once they find out. > > -DR- > > OPOD - Open POD The file extensions could be .opd ??? -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From b0ef at esben-stien.name Thu May 4 01:37:52 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed May 3 23:39:48 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <20060503232242.E62168B373@xprdmxin.myway.com> (spikethehobbitmage@excite.com's message of "Wed, 3 May 2006 19:22:42 -0400 (EDT)") References: <20060503232242.E62168B373@xprdmxin.myway.com> Message-ID: <87psiumjtb.fsf@esben-stien.name> "" writes: > If 192kHz is to high we can always slow it down. 96 or 48 would > allow more processing power to be used for other things. That's in not the concern. You see, it is mathematically not necessary to sample at 192kHz. Only reason for doing 96kHz is because of the sharp filters you would need at something like 48kHz. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From S.W.Harris at ecs.soton.ac.uk Thu May 4 03:46:40 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu May 4 03:47:00 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <1146706709.22500.5.camel@DaveLap> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> Message-ID: <20060504074640.GD997@login.ecs.soton.ac.uk> On Wed, May 03, 2006 at 09:38:28 -0400, Dave Robillard wrote: > > Before further discussing the name "Pod", please have a look at > > www.line6.com/products/pods/ . There is a whole family of FX processors > > for guitar and bass under the registered trademark "POD", and these > > devices are well known and widely used. So it?s probably not a good idea > > to name a software effects collection "Pod". > > This is a good point. The POD line is _VERY_ well known, and given that > plugins can be effects or guitar amp models etc (ie the domain is > similar) I wouldn't be surprised if Line6's lawyers had something to say > about it once they find out. Indeed. When I first googled it if didn't seem that close (amp sim hardware v's a software bundle format), but after sleeping on it I think it's much too close in function. - Steve From S.W.Harris at ecs.soton.ac.uk Thu May 4 04:11:14 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu May 4 04:11:33 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <44595FA2.7090807@boosthardware.com> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> <44595FA2.7090807@boosthardware.com> Message-ID: <20060504081113.GE997@login.ecs.soton.ac.uk> On Thu, May 04, 2006 at 08:57:54 +0700, Patrick Shirkey wrote: > Dave Robillard wrote: > > > >This is a good point. The POD line is _VERY_ well known, and given that > >plugins can be effects or guitar amp models etc (ie the domain is > >similar) I wouldn't be surprised if Line6's lawyers had something to say > >about it once they find out. > > > >-DR- > > > > > > OPOD - Open POD > > The file extensions could be .opd I had a very very similar idea: OpenPOD, OPOD being a non-cannonical abbreviation, extension .opod. By my own metric is level 3/0 crapness :) There are a bunch of openpod/oped things, none of them are relevant though (I expexted a bunch of mp3 player related stuff, but no). Openpod.org is a free software news site. Because it's $word$word we'd have to go for a slightly crap TLD. I think I like it, but it's not ultra-stellar-fantastic. Before anyone suggests it, FreePod is a piece of windows malware amongst other things :) - Steve From jussi.laako at pp.inet.fi Thu May 4 12:14:17 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu May 4 12:14:25 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <87psiumjtb.fsf@esben-stien.name> References: <20060503232242.E62168B373@xprdmxin.myway.com> <87psiumjtb.fsf@esben-stien.name> Message-ID: <445A2859.6030705@pp.inet.fi> Esben Stien wrote: >> If 192kHz is to high we can always slow it down. 96 or 48 would >> allow more processing power to be used for other things. > > That's in not the concern. You see, it is mathematically not necessary > to sample at 192kHz. Only reason for doing 96kHz is because of the Depends on what you are doing. When working on ultrasound it just makes life easier (no need to do undersampling). - Jussi From rlrevell at joe-job.com Fri May 5 00:00:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri May 5 00:01:14 2006 Subject: [linux-audio-dev] Preliminary spec for OpenGraphics soundcard In-Reply-To: <20060503073727.AC88C8B50D@xprdmxin.myway.com> References: <20060503073727.AC88C8B50D@xprdmxin.myway.com> Message-ID: <1146801655.18891.0.camel@mindpipe> On Wed, 2006-05-03 at 03:37 -0400, spikethehobbitmage@excite.com wrote: > OS > embedded Linux to start with (at least until design is proofed) > a true RTOS would be preferable Linux with the -rt patch is a true RTOS. Lee From fons.adriaensen at alcatelaleniaspace.com Fri May 5 04:44:59 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri May 5 04:45:08 2006 Subject: [linux-audio-dev] surround multimedia SW on Linux Message-ID: <20060505084458.GA16795@bth05w.ABSp.alcatel.be> I've had this request on a non-Linux list: Can you provide more feedback (about) ... multimedia players capable of decoding Dolby AC3, DTS, DVD-Audio, etc. on a Linux machine? What about software players running on a CAR-PC and surround-capable? I know very little about the whole field of multimedia players for proprietary formats on Linux. Can someone fill in the gaps ? - which apps are available ? - are they open-source ? - what interfaces (ALSA, JACK, OSS, ...) do they have ? - do they require Windoze emulation ? - what is their maintenance state ? - etc. Many thanks, -- FA Follie! Follie! Delirio vano e' questo! From ce at christeck.de Fri May 5 07:17:24 2006 From: ce at christeck.de (Christoph Eckert) Date: Fri May 5 07:16:05 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] LAC2006 Photos In-Reply-To: <200605011816.44731.ce@christeck.de> References: <200605011816.44731.ce@christeck.de> Message-ID: <200605051317.25141.ce@christeck.de> Hi, as of request, I've just modified some of the filenames to give you a clue who some of the people are. Location same as before: http://christeck.de/stuff/LAC2006.tar.gz Will be up in half an hour. Best regards ce From paniq at paniq.org Fri May 5 15:04:01 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Fri May 5 14:55:22 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <20060504081113.GE997@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> <44595FA2.7090807@boosthardware.com> <20060504081113.GE997@login.ecs.soton.ac.uk> Message-ID: <1146855841.2862.31.camel@localhost> On Thu, 2006-05-04 at 09:11 +0100, Steve Harris wrote: > Before anyone suggests it, FreePod is a piece of windows malware amongst > other things :) following this thread for quite a while i conclude that it is impossible to find a name that sounds good and does _not_ mean anything. do something irrational please. :) -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From rlrevell at joe-job.com Fri May 5 19:06:00 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri May 5 19:06:10 2006 Subject: [linux-audio-dev] n00b friendly latency tester Message-ID: <1146870361.12995.16.camel@mindpipe> After some discussions at LAC I think a user friendly latency tester is needed so users have an easy way to test a setup, something better than than just installing apps and being mystified when they get tons of xruns. The backend is trivial (there are a bunch of similar little tools out there), but I'm not a GUI person. Would anyone like to help design and implement this? Since time is money ;-) a simple Gnome and/or KDE front end would be the easiest way to start, and of course there should be a separation between the GUI and the back end so anyone can implement a leaner version if they want to. Anyone want to help with the GUI side? Lee From dominic.sacre at gmx.de Fri May 5 23:54:15 2006 From: dominic.sacre at gmx.de (Dominic =?iso-8859-1?q?Sacr=E9?=) Date: Fri May 5 23:57:29 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <1146870361.12995.16.camel@mindpipe> References: <1146870361.12995.16.camel@mindpipe> Message-ID: <200605060554.15754.dominic.sacre@gmx.de> On Saturday, 6. May 2006 01:06, Lee Revell wrote: > After some discussions at LAC I think a user friendly latency tester is > needed so users have an easy way to test a setup, something better than > than just installing apps and being mystified when they get tons of > xruns. I think that would be very useful. Exactly what kind of latencies would this tool measure? > The backend is trivial (there are a bunch of similar little tools out > there), but I'm not a GUI person. Would anyone like to help design and > implement this? Since time is money ;-) a simple Gnome and/or KDE > front end would be the easiest way to start, and of course there should > be a separation between the GUI and the back end so anyone can > implement a leaner version if they want to. Anyone want to help with > the GUI side? To me the GUI appears a lot more trivial than the backend :) So I'd like to offer my help writing a GTK frontend (steering clear of any particular Gnome/KDE dependencies). Are you going to make a fully functional command line version? Dominic From ix at replic.net Sat May 6 00:19:45 2006 From: ix at replic.net (carmen) Date: Sat May 6 00:19:50 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <200605060554.15754.dominic.sacre@gmx.de> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> Message-ID: <20060506041945.GB9616@replic.net> > > The backend is trivial (there are a bunch of similar little tools out > > there) > Are you going to make a fully functional command line version? in my experience usually either 'it works' or 'its completely fucked' and some arbitrary latency number is going to state the obvious. for example after doing a bunch of things like switching to trunk xorg where the radeon drivers finally support the card im using for 2D, switching to linux 2.6.17 and building jack, alsa-lib, and the kernel with gcc 3.x (lots of weird divide by zero segfaults in alsa-lib calls from jack with gcc 4.x, according to GDB and dmesg) and doing an emerge -DNu world after adding the pro-audio overlay (which updated pam among other things) everything finally works. still cant get RT to boot but at least its no longer the necessary 'holy grail' here.. it would be good to build up a database so people know which motherboards to avoid. and to get a sense of these new 'experimental mutex rewrite' branches from ingo get us into the petasecond range - my tips for the UI would be some kind of horizontal pie-chart seperating the latency components into different contets, like DA latency, alsa cals, app internal buffering, jackd buffering, etc.. From rlrevell at joe-job.com Sat May 6 10:08:42 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 6 10:08:54 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <20060506041945.GB9616@replic.net> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <20060506041945.GB9616@replic.net> Message-ID: <1146924523.15364.69.camel@mindpipe> On Sat, 2006-05-06 at 04:19 +0000, carmen wrote: > still cant get RT to boot AMD64 by any chance? What are the exact symptoms? Please send me your exact config (off list) Lee From rlrevell at joe-job.com Sat May 6 10:13:42 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 6 10:13:52 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <200605060554.15754.dominic.sacre@gmx.de> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> Message-ID: <1146924823.15364.73.camel@mindpipe> On Sat, 2006-05-06 at 05:54 +0200, Dominic Sacr? wrote: > On Saturday, 6. May 2006 01:06, Lee Revell wrote: > > After some discussions at LAC I think a user friendly latency tester is > > needed so users have an easy way to test a setup, something better than > > than just installing apps and being mystified when they get tons of > > xruns. > > I think that would be very useful. Exactly what kind of latencies would > this tool measure? > Same as the existing CLI tools - it would start an RT thread that polls on the RTC, then tell the user to generate some load (switch windows, do a find /, pingflood the default gateway, whatever), then report back the maximum latency. > > The backend is trivial (there are a bunch of similar little tools out > > there), but I'm not a GUI person. Would anyone like to help design and > > implement this? Since time is money ;-) a simple Gnome and/or KDE > > front end would be the easiest way to start, and of course there should > > be a separation between the GUI and the back end so anyone can > > implement a leaner version if they want to. Anyone want to help with > > the GUI side? > > To me the GUI appears a lot more trivial than the backend :) So I'd like > to offer my help writing a GTK frontend (steering clear of any particular > Gnome/KDE dependencies). > > Are you going to make a fully functional command line version? I'd like to, this is why I said the GUI should be separate from the back end. I don't have the bandwidth to do the whole thing - I need someone (or a few people) to make a mockup GUI and then I'll wire up the buttons. Lee From larsl at users.sourceforge.net Sat May 6 10:45:01 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat May 6 10:45:19 2006 Subject: [linux-audio-dev] [ANN] Dino 0.2 Message-ID: <1146926701.7945.6.camel@localhost> Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK transport to send MIDI events to synths and synchronise with other sequencers or transport aware programs. It uses LASH to save and restore sessions. This is the first release. Get it at http://dinoseq.sf.net . Requirements: * libglademm >= 2.4.1 * libxml++ >= 2.6.1 * JACK >= 0.100 with the MIDI patch available here: http://www.custard.org/~deviant/jack-midi/ * LASH >= 0.5.0 -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060506/cad85300/attachment.bin From cuse at users.sourceforge.net Sat May 6 12:30:18 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Sat May 6 12:30:30 2006 Subject: [linux-audio-dev] [ANN] Dino 0.2 In-Reply-To: <1146926701.7945.6.camel@localhost> References: <1146926701.7945.6.camel@localhost> Message-ID: <200605061830.19940.cuse@users.sourceforge.net> Es geschah am Saturday, 6. May 2006 16:45 als Lars Luthman schrieb: > Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK I just realized that I live on the moon... since when does JACK support MIDI? CU Christian From jesse at essej.net Sat May 6 12:37:34 2006 From: jesse at essej.net (Jesse Chappell) Date: Sat May 6 12:37:41 2006 Subject: [linux-audio-dev] [ANN] Dino 0.2 In-Reply-To: <200605061830.19940.cuse@users.sourceforge.net> References: <1146926701.7945.6.camel@localhost> <200605061830.19940.cuse@users.sourceforge.net> Message-ID: On 5/6/06, Christian Schoenebeck wrote: > Es geschah am Saturday, 6. May 2006 16:45 als Lars Luthman schrieb: > > Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK > > I just realized that I live on the moon... since when does JACK support MIDI? Unofficially for a while (via a patch), but that patch just made it into JACK CVS this week. jlc From torbenh at gmx.de Sat May 6 12:48:30 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat May 6 12:51:37 2006 Subject: [linux-audio-dev] [ANN] Dino 0.2 In-Reply-To: References: <1146926701.7945.6.camel@localhost> <200605061830.19940.cuse@users.sourceforge.net> Message-ID: <20060506164830.GA8142@mobilat> On Sat, May 06, 2006 at 12:37:34PM -0400, Jesse Chappell wrote: > On 5/6/06, Christian Schoenebeck wrote: > >Es geschah am Saturday, 6. May 2006 16:45 als Lars Luthman schrieb: > >> Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK > > > >I just realized that I live on the moon... since when does JACK support > >MIDI? > > Unofficially for a while (via a patch), but that patch just made it > into JACK CVS this week. WOOOOOOOOOOOOOT.......... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From larsl at users.sourceforge.net Sat May 6 15:51:47 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat May 6 15:51:58 2006 Subject: [linux-audio-dev] [ANN] Dino 0.2 In-Reply-To: <200605061830.19940.cuse@users.sourceforge.net> References: <1146926701.7945.6.camel@localhost> <200605061830.19940.cuse@users.sourceforge.net> Message-ID: <1146945107.7945.11.camel@localhost> On Sat, 2006-05-06 at 18:30 +0200, Christian Schoenebeck wrote: > Es geschah am Saturday, 6. May 2006 16:45 als Lars Luthman schrieb: > > Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK > > I just realized that I live on the moon... since when does JACK support MIDI? Since more than two years, using a patch. It's not in any release yet though. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060506/49a51301/attachment-0001.bin From rncbc at rncbc.org Sat May 6 16:36:29 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sat May 6 16:37:10 2006 Subject: [linux-audio-dev] My LAC2006 Photos In-Reply-To: <200605011816.44731.ce@christeck.de> References: <200605011816.44731.ce@christeck.de> Message-ID: <445D08CD.2090003@rncbc.org> Hi everybody, Some (lousy) photos taken by myself during LAC2006 ZKM Karlsruhe. Presented in some hacky web gallery at my own personal home server: http://www.rncbc.org/lac2006 Subjects are: netjack-workshop, jacklab-workshop, linux-sound-night + plug-n-chill, final-group-photo and last-night-at-the-restaurant. Timestamps are local times. Click on a thumbnail to download the developed copy ;) Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From rlrevell at joe-job.com Sat May 6 18:18:25 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 6 18:18:38 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] My LAC2006 Photos In-Reply-To: <445D08CD.2090003@rncbc.org> References: <200605011816.44731.ce@christeck.de> <445D08CD.2090003@rncbc.org> Message-ID: <1146953906.15364.148.camel@mindpipe> On Sat, 2006-05-06 at 21:36 +0100, Rui Nuno Capela wrote: > Hi everybody, > > Some (lousy) photos taken by myself during LAC2006 ZKM Karlsruhe. > Presented in some hacky web gallery at my own personal home server: > > http://www.rncbc.org/lac2006 > > Subjects are: netjack-workshop, jacklab-workshop, linux-sound-night + > plug-n-chill, final-group-photo and last-night-at-the-restaurant. > Timestamps are local times. > > Click on a thumbnail to download the developed copy ;) Good stuff! I wish berlin was next week ;-) Lee From ce at christeck.de Sat May 6 20:15:38 2006 From: ce at christeck.de (Christoph Eckert) Date: Sat May 6 20:14:16 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] My LAC2006 Photos In-Reply-To: <1146953906.15364.148.camel@mindpipe> References: <200605011816.44731.ce@christeck.de> <445D08CD.2090003@rncbc.org> <1146953906.15364.148.camel@mindpipe> Message-ID: <200605070215.38912.ce@christeck.de> > Good stuff! ?I wish berlin was next week ;-) Nice you enjoyed the show ;-) . Best regards ce From dominic.sacre at gmx.de Sat May 6 20:25:45 2006 From: dominic.sacre at gmx.de (Dominic =?iso-8859-1?q?Sacr=E9?=) Date: Sat May 6 20:27:01 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <1146924823.15364.73.camel@mindpipe> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> Message-ID: <200605070225.45570.dominic.sacre@gmx.de> On Saturday, 6. May 2006 16:13, Lee Revell wrote: > > I think that would be very useful. Exactly what kind of latencies > > would this tool measure? > > Same as the existing CLI tools - it would start an RT thread that polls > on the RTC, then tell the user to generate some load (switch windows, > do a find /, pingflood the default gateway, whatever), then report back > the maximum latency. Could you give me some links to these tools? I know I've seen something like this, but I'm unable to find it... How do these tools relate to the latency tracer in the realtime kernel? Dominic From rlrevell at joe-job.com Sat May 6 20:35:07 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 6 20:35:17 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <200605070225.45570.dominic.sacre@gmx.de> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> <200605070225.45570.dominic.sacre@gmx.de> Message-ID: <1146962108.15364.158.camel@mindpipe> On Sun, 2006-05-07 at 02:25 +0200, Dominic Sacr? wrote: > On Saturday, 6. May 2006 16:13, Lee Revell wrote: > > > I think that would be very useful. Exactly what kind of latencies > > > would this tool measure? > > > > Same as the existing CLI tools - it would start an RT thread that polls > > on the RTC, then tell the user to generate some load (switch windows, > > do a find /, pingflood the default gateway, whatever), then report back > > the maximum latency. > > Could you give me some links to these tools? I know I've seen something > like this, but I'm unable to find it... I think Florian Schmidt's web site has the latest latency tester. > How do these tools relate to the latency tracer in the realtime kernel? > The tester is a userspace tool to measure low latency performance, the latency tracer is an in-kernel mechanism to determine which part of the kernel might be causing a latency problem. > Dominic > From jens.andreasen at chello.se Sun May 7 03:26:00 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun May 7 03:26:13 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <1146855841.2862.31.camel@localhost> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> <44595FA2.7090807@boosthardware.com> <20060504081113.GE997@login.ecs.soton.ac.uk> <1146855841.2862.31.camel@localhost> Message-ID: <1146986760.11374.9.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2006-05-05 at 21:04 +0200, Leonard "paniq" Ritter wrote: > > On Thu, 2006-05-04 at 09:11 +0100, Steve Harris wrote: > > Before anyone suggests it, FreePod is a piece of windows malware amongst > > other things :) > > following this thread for quite a while i conclude that it is impossible > to find a name that sounds good and does _not_ mean anything. > > do something irrational please. :) > > Something new that is still very much like the old, but with only 3 or 4 letters? By dropping the 'A' in LADSPA it could become LDSP ("ell-dis-pea") -- From mista.tapas at gmx.net Sun May 7 06:56:59 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Sun May 7 06:57:10 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <1146962108.15364.158.camel@mindpipe> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> <200605070225.45570.dominic.sacre@gmx.de> <1146962108.15364.158.camel@mindpipe> Message-ID: <20060507125659.4eba8f63@mango.fruits> On Sat, 06 May 2006 20:35:07 -0400 Lee Revell wrote: > > > Same as the existing CLI tools - it would start an RT thread that polls > > > on the RTC, then tell the user to generate some load (switch windows, > > > do a find /, pingflood the default gateway, whatever), then report back > > > the maximum latency. > > > > Could you give me some links to these tools? I know I've seen something > > like this, but I'm unable to find it... > > I think Florian Schmidt's web site has the latest latency tester. > > > How do these tools relate to the latency tracer in the realtime kernel? > > > > The tester is a userspace tool to measure low latency performance, the > latency tracer is an in-kernel mechanism to determine which part of the > kernel might be causing a latency problem. You can get the tarball from this page: http://tapas.affenbande.org/?page_id=15 [Some elaborations for the OP]: Of course, as this uses the RTC and not the soundcard it cannot account for i.e. buggy soundcard drivers [i have a cs46xx card that _always_ produces some xruns no matter how well tuned the system is. No such problems with my delta 66]. I kinda thought rtc_wakeup was obsolete these days, as the kernel tools are a much better instrument [assuming you use a -rt kernel, or does vanilla have the latency tracing et. al. stuff these days, too?]. So maybe it is still useful for a non-rt kernel. But what serious audio user would use a non-rt kernel? On a 2.6.15.4 kernel with low latency desktop setting [non-rt] i get a max jitter of [after like 5 minutes running]: new max. jitter: 68.4% (667 usec) which looks pretty good. But it seems jackd has some more weak points than rtc_wakeup [which is very simple]. For example on this kernel running jack with a periodsize of 256 at a samplerate of 48khz _seems_ to run fine even with a find / or two. But beware. Copying large files to /dev/null makes jackd sometimes produce xruns in the range of tens to hundreds of ms -> ugh. rtc_wakeup OTOH is not affected by this. I suspect the culprit is the FS [which jack depends on through its use of pipes to do the interprocess wakeup]. But only -rt instruments could tell us what's really up. It seems -rt kernels have the latency tracing mechanisms available even when not using full preemption. But i'm too lazy right now ;) Flo -- Palimm Palimm! http://tapas.affenbande.org From capocasa at gmx.net Sun May 7 08:33:44 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sun May 7 08:34:01 2006 Subject: [linux-audio-dev] Re: "LADSPA2" naming redux In-Reply-To: <20060503102844.GA4662@login.ecs.soton.ac.uk> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> Message-ID: Well, it does seem heavily Steve Jobs influenced... Of course it's hard to please everybody but personally I just love to see some really original stuff perhaps even with a little penguin appeal. PLUX was really good for that one IMHO... But, great to see you ask for opinions, I'm copying you on that one :) Carlo From rlrevell at joe-job.com Sun May 7 09:22:54 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun May 7 09:23:03 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <20060507125659.4eba8f63@mango.fruits> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> <200605070225.45570.dominic.sacre@gmx.de> <1146962108.15364.158.camel@mindpipe> <20060507125659.4eba8f63@mango.fruits> Message-ID: <1147008175.15364.184.camel@mindpipe> On Sun, 2006-05-07 at 12:56 +0200, Florian Paul Schmidt wrote: > I kinda thought rtc_wakeup was obsolete these days, as the kernel > tools are a much better instrument [assuming you use a -rt kernel, or > does vanilla have the latency tracing et. al. stuff these days, too?]. > So maybe it is still useful for a non-rt kernel. But what serious > audio user would use a non-rt kernel? I think more will use the mainline kernel as it gets better (keyboard players are perfectly fine with 5ms latency which mainline can certainly deliver). And the latency tracer has overhead (if you oprofile it you will see mcount() eats 1-2% of your CPU), and is complicated for users who aren't linux experts to use. We know the -rt kernel is OK for audio, but it would be nice to be able to tell users "is this random kernel that I am running likely to be OK for audio" Lee From errandir_news at mph.eclipse.co.uk Sun May 7 11:16:24 2006 From: errandir_news at mph.eclipse.co.uk (Martin Habets) Date: Sun May 7 11:16:35 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <1146924823.15364.73.camel@mindpipe> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> Message-ID: <20060507151624.GA3258@palantir8> On Sat, May 06, 2006 at 10:13:42AM -0400, Lee Revell wrote: > Same as the existing CLI tools - it would start an RT thread that polls > on the RTC, then tell the user to generate some load (switch windows, do > a find /, pingflood the default gateway, whatever), then report back the > maximum latency. In stead of telling the user to generate some (unpredictable) load I would suggest re-using the parts from the alsa latency tester tool that automatically spawn another process with a known load. Just my 2 cents. -- Martin From rlrevell at joe-job.com Sun May 7 11:43:47 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun May 7 11:44:08 2006 Subject: [linux-audio-dev] n00b friendly latency tester In-Reply-To: <20060507151624.GA3258@palantir8> References: <1146870361.12995.16.camel@mindpipe> <200605060554.15754.dominic.sacre@gmx.de> <1146924823.15364.73.camel@mindpipe> <20060507151624.GA3258@palantir8> Message-ID: <1147016627.15364.216.camel@mindpipe> On Sun, 2006-05-07 at 16:16 +0100, Martin Habets wrote: > On Sat, May 06, 2006 at 10:13:42AM -0400, Lee Revell wrote: > > Same as the existing CLI tools - it would start an RT thread that polls > > on the RTC, then tell the user to generate some load (switch windows, do > > a find /, pingflood the default gateway, whatever), then report back the > > maximum latency. > > In stead of telling the user to generate some (unpredictable) load I would > suggest re-using the parts from the alsa latency tester tool that automatically > spawn another process with a known load. Yeah I was thinking about this. There are workloads that cause xruns (like display activity with some video drivers) that are hard to simulate this way. Maybe we could generate some load and tell the user to generate their own load at the same time. Lee From ix at replic.net Sun May 7 15:35:37 2006 From: ix at replic.net (carmen) Date: Sun May 7 15:35:43 2006 Subject: [linux-audio-dev] Re: "LADSPA2" naming redux In-Reply-To: References: <20060503102844.GA4662@login.ecs.soton.ac.uk> Message-ID: <20060507193537.GA27049@replic.net> On Sun May 07, 2006 at 02:33:44PM +0200, Carlo Capocasa wrote: > Well, it does seem heavily Steve Jobs influenced... Of course it's hard > to please everybody but personally I just love to see some really > original stuff perhaps even with a little penguin appeal. PLUX was > really good for that one IMHO... PLEX was also the name of a (imo nausea inducing) VST plugin from Steinberg. imo the name is not important at all. as long as the plugins are ubiquitous, users will just be able to use them without thinking "does this host support LADSPA2? how aobut REduzPlug? V(f)ST?). tons of people use Ubuntu without knowing what GlibC or GTK are... From torbenh at gmx.de Mon May 8 01:32:06 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Mon May 8 01:35:11 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060501212756.GD28107@login.ecs.soton.ac.uk> References: <1146324278.7932.12.camel@localhost> <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> Message-ID: <20060508053206.GA11626@mobilat> On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: > On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: > > On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: > > > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: > > > > I guess the port things aren't a good justification for the creation > > > > parameters, you're right. The question, then, is what is the > > > > recommended way for the host to provide functions to the plugin? That's > > > > what Lars was originally seeking (and solves the above allocation > > > > problem as well) > > > > > > I think that if it's provided as part of a HostFeature (so the plugin > > > knows it exists and what it's called) it can be obtained using the OS's > > > normal dynamic linking functions. I've not tried though. > > > > Do you mean that the plugin should dlopen the host? Wouldn't that > > require some way to pass the path to the host program to the plugin (in > > which case you might as well pass a function pointer directly)? > > I mean the linker should do it. If you dynamically build the plugin > against a stub library and the host exports something with the same ABI, I > /think/ the plugin should have the host's version of the function in its > namespace. this is not TRUE on windows. otherwise yes. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From S.W.Harris at ecs.soton.ac.uk Mon May 8 04:07:48 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon May 8 04:08:10 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060508053206.GA11626@mobilat> References: <1146328934.2552.18.camel@DaveLap> <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> Message-ID: <20060508080748.GB15609@login.ecs.soton.ac.uk> On Mon, May 08, 2006 at 07:32:06 +0200, torbenh@gmx.de wrote: > > I mean the linker should do it. If you dynamically build the plugin > > against a stub library and the host exports something with the same ABI, I > > /think/ the plugin should have the host's version of the function in its > > namespace. > > this is not TRUE on windows. > otherwise yes. Ah, well thats kind of important. I understand that Windows is quite popular in some places? ;) Is there some equivalent mechanism that lets dlloaded plugins dig function pointers out of the the host? Thier public symbol linking system is backward too from what I remember. I don't think theres any reason to stop Windows users being able to share the love, should they so choose. I used to get a lot of mail asking for advice on how to compile my plugins on Windows until I put a note on the website saying I couldn't help. - Steve From parumi at iua.upf.edu Mon May 8 13:33:06 2006 From: parumi at iua.upf.edu (Pau Arumi) Date: Mon May 8 13:24:13 2006 Subject: [linux-audio-dev] CLAM Music Annotator 0.3.1 released Message-ID: <445F80D2.70406@iua.upf.edu> May 8th 2006, CLAM Music Annotator 0.3.1 released What is the CLAM Music Annotator? --------------------------------- Is an application of the CLAM framework [1] that can be used to visualise, check and modify music information extracted from audio: low level features, note segmentation, chords, structure... The tool is intended to be useful for (though not limited to) the music information retrieval research whenever you need to: - Supervise and correct the results of automated audio feature extraction algorithms - Generate manually edited annotations of audio as training examples or ground truth for those algorithms. You can learn more about Music Annotator in its wiki page, which includes screenshots and videos galleries: http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator The application comes with two example extractors. One that computes low level descriptors and another that performs chord detection. It also features useful views such as the "tonnetz" and "key space" to visualise the tonal features (chords, notes...) CLAM Music Annotator is GPL. What's new from last (0.2) version ? ------------------------------------ This is a major release which have at least duplicated the number of important features. - Ported to Qt4 - New chord extractor - Colourful animated visualisations - Improved application work-flow (project building, etc.) - It also works as a collaborative annotation tool (BOCA client) See the changelog [2] for a complete list of changes. or the wiki [3] for general information. How to install it? ------------------ In Windows we provide a binary installer which includes all the needed libraries (including Qt4) and ready-to-use sample data. For Linux and Mac OSX we don't provide binaries at this moment (though we plan to do in short). Source tarballs can be downloaded from the web and complete build instructions can be found in the INSTALL file. http://clam.iua.upf.edu/download.html Acknowledgements ----------------- This project is partially founded by SIMAC European Project, IST-507142 and Catalunya's Government, exp 200/05 ST The chord extractor extracts segments labeled with chords. It uses Christopher Harte algorithm with some minor variations. It has been developed as a collaboration between the Queen Mary University of London and the Universitat Pompeu Fabra (UPF) of Barcelona. The "keyspace" view is a great contribution of Jordi Bonada and Emilia Gomez, at UPF. The CLAM team Music Tecnology Group Universitat Pompeu Fabra (Barcelona) References: 1. http://clam.iua.upf.edu 2. http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator_Changelog 3. http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator From t_w_ at freenet.de Mon May 8 13:28:22 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Mon May 8 13:28:32 2006 Subject: [linux-audio-dev] LADSPA 2 name Message-ID: <20060508172822.GB7353@charly.SWORD> Hi! Requirements in order of importance, highest first: - not likely to get us into legal trouble - no too obvious negative interpretations/associations ("too obvious" because it's too hard, internationaly, otherwise) - no conflict with established open source projects - easy to search for Pretty much every 3 letter combo is in use by some company or institute. Few are pronounceable. It's similar with 4 letters. Suggestions with few (and not relevant looking) or no Google hits: splugs - stream processing plugins sppib - stream processing plugins in bundles laspib - linux audio ... buspp - bundled stream processing plugins streamins - streaming/stream-processing plugins sprocins - stream processing plugins [Streaming because there are continuous i/o streams of data as far as I understand, while there's no limitation to audio/float anymore. Corect me if I'm wrong.] Cheers, Thorsten Wilms From jdboyd at jdboyd.net Mon May 8 13:20:28 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Mon May 8 13:35:30 2006 Subject: [linux-audio-dev] Re: NAB trade show In-Reply-To: <200605021728.36402.ben@glw.com> References: <20060502193015.53E52141D3B5@music.columbia.edu> <200605021728.36402.ben@glw.com> Message-ID: <20060508172028.GB24201@jdboyd.zill.net> On Tue, May 02, 2006 at 05:28:36PM -0500, Ben Loftis wrote: > > > > So what did you see? > > > > Not much honestly. Digi was demo'ing the new version of PT but they are just > playing catchup with the innovative companies at this point. The coolest > thing at the show was definitely Ardour, which we were using as a playback > and recording machine for our mixing consoles. Man, I wish I had seen that. Next year, maybe we need a LinuxAudio NAB guide of what cool linux audio stuff to look for. Maybe I'll remember to set up a wiki for something like this next spring. Also, SpectSoft (maker of a Linux based video DDR system) hosted a linux party this year. I'm fairly sure that audio people would be welcome, but they didn't get the word out in that direction at all. I'm going to suggest that to them for next year. One uplifting thing I saw was that Baselight (a digital film grading and finishing system from FilmLight) uses Jack for it's audio IO support. I don't know how much they do with audio, other than presumably record and play back tracks. I thought it was cool seeing them embrace Jack though rather than either inventing their own or sticking with safe old OSS. > > One this I've been wondering is how do the 5.1 upmix boxes work? The > > ones that take in stereo and convert it to surround sound. The sales > > There are infinite ways to do this and none of them make the music sound > better than stereo. OK I guess "better" is subjective but there's certainly > no "correct" way to do it. You can easily derive a center/sub channel but > most systems do something hideous when it comes to the rear channels. I'd imagine so. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From larsl at users.sourceforge.net Mon May 8 14:20:43 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Mon May 8 14:20:53 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060508172822.GB7353@charly.SWORD> References: <20060508172822.GB7353@charly.SWORD> Message-ID: <1147112443.8851.0.camel@localhost> On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote: > Hi! > > Requirements in order of importance, highest first: > - not likely to get us into legal trouble > - no too obvious negative interpretations/associations > ("too obvious" because it's too hard, internationaly, otherwise) > - no conflict with established open source projects > - easy to search for > > > Pretty much every 3 letter combo is in use by some company or > institute. Few are pronounceable. It's similar with 4 letters. > > > Suggestions with few (and not relevant looking) or no Google hits: > > splugs - stream processing plugins > sppib - stream processing plugins in bundles > laspib - linux audio ... > buspp - bundled stream processing plugins > streamins - streaming/stream-processing plugins > sprocins - stream processing plugins L2, where the L is for LADSPA. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060508/14bc2ea5/attachment-0001.bin From kouhia at nic.funet.fi Mon May 8 15:27:56 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Mon May 8 15:28:03 2006 Subject: [linux-audio-dev] Re: NAB trade show Message-ID: Anyone took photos at the show? Dieter Meier of Yello was in Avid's booth if I understood correctly. Dieter Meier is a member of board at Euphonix and perhaps now has business with Avid too. http://www.euphonix.com/news/news2002/021202_dieter_interview.htm A few guys at the Yello list visited the show but they had no camera with them. :-( Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From pw_lists at slinkp.com Mon May 8 15:29:46 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Mon May 8 15:28:59 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <1147112443.8851.0.camel@localhost> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> Message-ID: <20060508192946.GA11274@slinkp.com> On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote: > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote: > > Hi! > > > > Requirements in order of importance, highest first: > > - not likely to get us into legal trouble (snip) > L2, where the L is for LADSPA. http://www.waves.com/content.asp?id=139 -- Paul Winkler http://www.slinkp.com From S.W.Harris at ecs.soton.ac.uk Tue May 9 04:59:53 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 9 05:00:13 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060508192946.GA11274@slinkp.com> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> Message-ID: <20060509085953.GB25986@login.ecs.soton.ac.uk> On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote: > On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote: > > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote: > > > Hi! > > > > > > Requirements in order of importance, highest first: > > > - not likely to get us into legal trouble > (snip) > > L2, where the L is for LADSPA. > http://www.waves.com/content.asp?id=139 But I like the idea. LV2 is less taken. Nearest thing is a model of midi controller: http://www.dolphinmusic.co.uk/page/shop/flypage/product_id/8779 - Steve From S.W.Harris at ecs.soton.ac.uk Tue May 9 05:35:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 9 05:35:30 2006 Subject: [linux-audio-dev] "LADSPA2" naming redux In-Reply-To: <1146986760.11374.9.camel@c80-216-124-251.cm-upc.chello.se> References: <20060503102844.GA4662@login.ecs.soton.ac.uk> <4458F0CF.2060300@gmail.com> <4458F54A.9090105@boosthardware.com> <4458E645.5060906@gmx.de> <1146706709.22500.5.camel@DaveLap> <44595FA2.7090807@boosthardware.com> <20060504081113.GE997@login.ecs.soton.ac.uk> <1146855841.2862.31.camel@localhost> <1146986760.11374.9.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060509093511.GC25986@login.ecs.soton.ac.uk> On Sun, May 07, 2006 at 09:26:00AM +0200, Jens M Andreasen wrote: > On Fri, 2006-05-05 at 21:04 +0200, Leonard "paniq" Ritter wrote: > > > > On Thu, 2006-05-04 at 09:11 +0100, Steve Harris wrote: > > > Before anyone suggests it, FreePod is a piece of windows malware amongst > > > other things :) > > > > following this thread for quite a while i conclude that it is impossible > > to find a name that sounds good and does _not_ mean anything. > > > > do something irrational please. :) > > > > > Something new that is still very much like the old, but with only 3 or 4 > letters? > > By dropping the 'A' in LADSPA it could become LDSP ("ell-dis-pea") There was a yamaha preverb processor called an LDSP, I dont know if its still current though. - Steve From anthonykozar at sbcglobal.net Tue May 9 10:48:13 2006 From: anthonykozar at sbcglobal.net (Anthony Kozar) Date: Tue May 9 10:48:25 2006 Subject: [linux-audio-dev] [ANN] Bol Processor going Open Source! In-Reply-To: Message-ID: Dear Linux Audio Developers, Bernard Bel and I are very happy to announce to you that a powerful tool for computer-aided composition using Csound or Midi -- the Bol Processor -- is being reborn as open source software! While the software only runs on Macintosh computers at this time, we are hoping that some savvy Linux developers with porting experience will be interested in joining the project. Thanks! (And please email me directly if you want to see the source code in a more Linux-friendly format :) Details are below ... ---------- From: Bernard Bel Reply-To: bp2-list@yahoogroups.com Date: Mon, 8 May 2006 12:48:54 +0200 To: bp2-list@yahoogroups.com Subject: [bp2] Bol Processor going Open Source! [Please circulate] Bol Processor is a program for music composition and improvisation with real-time MIDI, MIDI file, and Csound output. It produces music from a set of rules (a compositional grammar) or from text scores typed or captured from a MIDI instrument. Bol Processor 2 was a shareware application developed by Bernard Bel with the help of Jim Kippen and Srikumar Karaikudi Subramanian. BP2 won the Bourges 1997 international award (ex aequo with Cecilia) in the category of computer-aided composition and realization software. More information about the capabilities of BP2 is available at . Bol Processor is now being released as free software (open source) under a BSD-style license. BP development is hosted by Sourceforge at . We are looking for several developers to join the project to help with porting and to decide the future directions that the software will take. If you are interested in helping, please email Anthony Kozar for more information. BP2 currently runs on the Classic MacOS. (However, its OMS MIDI driver, including QuickTime music, only runs on machines booting MacOS 9.) One of the goals of the open-source project will be to port it to other platforms. We are hoping that Bol Processor 3 will at least run on MacOS X, and ports to Windows and Linux are also possible depending on the desires and expertise of the group of developers that can be assembled. Two files are now available in the release section of the Bol Processor Sourceforge site. There is a MacOS disk image with the BP 2.9.5 beta application and another disk image with copies of all of the source files to build it. The source code has also been added to the BP CVS repository. This release is a snapshot of the current state of the project and interested developers are encouraged to download the files and start looking them over. Users will probably want to stick with version 2.9.3 for now but are welcome to try out 2.9.5 beta as well. Note that we have not yet removed the shareware registration notices, so please disregard them. There is a mailing list for discussion of BP2 at and there should soon be a developer mailing list hosted by the Sourceforge project. Please join and help us determine the future of Bol Processor !! Bernard Bel Anthony Kozar BP2 Yahoo! Groups Links <*> To visit the BP2 group on the web, go to: http://groups.yahoo.com/group/bp2-list/ <*> To subscribe from this group, send an email to: bp2-list-subscribe@yahoogroups.com From drobilla at connect.carleton.ca Tue May 9 12:26:30 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 9 12:28:38 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060509085953.GB25986@login.ecs.soton.ac.uk> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> Message-ID: <1147191990.3768.2.camel@DaveLap> On Tue, 2006-05-09 at 09:59 +0100, Steve Harris wrote: > On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote: > > On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote: > > > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote: > > > > Hi! > > > > > > > > Requirements in order of importance, highest first: > > > > - not likely to get us into legal trouble > > (snip) > > > L2, where the L is for LADSPA. > > http://www.waves.com/content.asp?id=139 > > But I like the idea. LV2 is less taken. Nearest thing is a model of midi > controller: > http://www.dolphinmusic.co.uk/page/shop/flypage/product_id/8779 I like LV2. Bit of a mouthful when spoken, but then so is VST. -DR- From dlphillips at woh.rr.com Tue May 9 16:36:24 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue May 9 16:32:49 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <1147191990.3768.2.camel@DaveLap> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <1147191990.3768.2.camel@DaveLap> Message-ID: <4460FD48.5000904@woh.rr.com> Dave Robillard wrote: >I like LV2. Bit of a mouthful when spoken, but then so is VST. > > If I recall correctly LV2 was the "rock" that the Nostromo set down on (in the movie "Alien"). So it's cool with me. :) From b0ef at esben-stien.name Wed May 10 01:12:33 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Tue May 9 23:14:40 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060509085953.GB25986@login.ecs.soton.ac.uk> (Steve Harris's message of "Tue, 9 May 2006 09:59:53 +0100") References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> Message-ID: <873bfipiny.fsf@esben-stien.name> Steve Harris writes: > LV2 What happened to the funny recursive acronyms?;). That they don't show up in a google search don't hold water; f.ex a search for JACK get you.. our beloved, sacred one. How about a girlie name to accompany JACK, then?;) Nothing beats daves' PEEP in any case..;) -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From andym00 at gmail.com Wed May 10 02:02:53 2006 From: andym00 at gmail.com (andym00@gmail.com) Date: Wed May 10 02:03:18 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <4460FD48.5000904@woh.rr.com> Message-ID: <008701c673f7$6812d9a0$0401a8c0@m00> Dave Phillips wrote: > If I recall correctly LV2 was the "rock" that the Nostromo > set down on (in the movie "Alien"). > > So it's cool with me. :) Actually that was LV4-26, but it's still cool ;) From S.W.Harris at ecs.soton.ac.uk Wed May 10 03:55:12 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 10 03:55:30 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <873bfipiny.fsf@esben-stien.name> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> Message-ID: <20060510075512.GA13700@login.ecs.soton.ac.uk> On Wed, May 10, 2006 at 07:12:33 +0200, Esben Stien wrote: > Steve Harris writes: > > > LV2 > > What happened to the funny recursive acronyms?;). That they don't show > up in a google search don't hold water; f.ex a search for JACK get > you.. our beloved, sacred one. They seem to be too much a matter of taste, and/or have negative connotations in various languages. Trying to get everyone to agree on one is just too much effort. Feel free to try and get consensus on a word-like name, but I've lost all enthusiasm for it. I think it's telling that the hardest part of this whole process has been choosing a name, classic colour of the bikeshed problem. You can argue that the name is important, but we've been happily using LADSPA for years, and that's terrible by alomost any metric. I've started using the name LV2 myself, if it doesn't annoy me within a week or so, and no-one comes up with a sensible objection it will probably become permenant. So, if you really hate it speak up now. > Nothing beats daves' PEEP in any case..;) Someone was allready using it for a free software project, and it's visually too close to BEEP which is a widely used protocol library. - Steve From v2 at iki.fi Wed May 10 04:24:08 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Wed May 10 04:24:18 2006 Subject: [linux-audio-dev] LADSPA 2 name Message-ID: <1147249448.4461a32815abc@www2.helsinki.fi> Quoting Esben Stien : > Steve Harris writes: > > > LV2 > > What happened to the funny recursive acronyms?;). That they don't show > up in a google search don't hold water; f.ex a search for JACK get > you.. our beloved, sacred one. > > How about a girlie name to accompany JACK, then?;) How about both recursive and a girlie name? BELLA = BELLA Effects Layer for Linux Audio (B could also be Bitchin') Sampo From S.W.Harris at ecs.soton.ac.uk Wed May 10 05:12:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 10 05:13:04 2006 Subject: [linux-audio-dev] This weeks changes to =?iso-8859-1?q?LV2_=28n=E9e?= LADSPA2) strawman examples Message-ID: <20060510091234.GC13700@login.ecs.soton.ac.uk> http://plugin.org.uk/ladspa2/ Changed name of the port shortname property to "symbol", which hopefully implies more the right thing. Added Rate before Control and Audio port names to hopefully make thier menaing clearer for people who may not come from a LADSPA background. This is just fiddling really, so I think it's starting to settle down. - Steve From dlphillips at woh.rr.com Wed May 10 06:47:14 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed May 10 06:43:37 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <008701c673f7$6812d9a0$0401a8c0@m00> References: <008701c673f7$6812d9a0$0401a8c0@m00> Message-ID: <4461C4B2.1070300@woh.rr.com> andym00@gmail.com wrote: >Dave Phillips wrote: > > >>If I recall correctly LV2 was the "rock" that the Nostromo >>set down on (in the movie "Alien"). >> >>So it's cool with me. :) >> >> > >Actually that was LV4-26, but it's still cool ;) > Yep, you right. Rats, I really wanted it to be that rock... :) Best, dp From b0ef at esben-stien.name Wed May 10 08:55:13 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed May 10 06:57:16 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060510075512.GA13700@login.ecs.soton.ac.uk> (Steve Harris's message of "Wed, 10 May 2006 08:55:12 +0100") References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> Message-ID: <87vesenioe.fsf@esben-stien.name> Steve Harris writes: > if you really hate it speak up now. BEAP Environment for Audio Plugins BAM Audio Mangling ZAP Audio Plugins A brainstorm on KLANK, PLOINK, SPLAT, SPLASH, BANG, KABOOM, CRASH, etc;) A name means a lot, in my opinion. It's about taking care of every corner case;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From rlrevell at joe-job.com Wed May 10 07:07:29 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed May 10 07:08:00 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <87vesenioe.fsf@esben-stien.name> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> Message-ID: <1147259251.18750.85.camel@mindpipe> On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: > ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional From sk at k-hornz.de Wed May 10 07:42:16 2006 From: sk at k-hornz.de (stefan kersten) Date: Wed May 10 07:42:29 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060508080748.GB15609@login.ecs.soton.ac.uk> References: <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> Message-ID: <20060510114216.GF12136@localdomain> On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > Is there some equivalent mechanism that lets dlloaded > plugins dig function pointers out of the the host? Thier > public symbol linking system is backward too from what I > remember. one portable way is to pass a struct of function pointers filled by the host to the plugin initialization function, as done in the SuperCollider server plugin API. From list at phasorlab.de Wed May 10 08:14:52 2006 From: list at phasorlab.de (Matthias Koenig) Date: Wed May 10 08:15:17 2006 Subject: [linux-audio-dev] LADSPA 2 name References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> <1147259251.18750.85.camel@mindpipe> Message-ID: <8764keqdoj.fsf@zebra.localdomain> Lee Revell writes: > On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: >> ZAP Audio Plugins > > I like this one, especially if the R. Crumb reference is intentional He he, ZAP has in the 90s also been the name of a german Hardcore/Punk Fanzine. Matthias From S.W.Harris at ecs.soton.ac.uk Wed May 10 08:22:38 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 10 08:23:14 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060510114216.GF12136@localdomain> References: <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> <20060510114216.GF12136@localdomain> Message-ID: <20060510122238.GD13700@login.ecs.soton.ac.uk> On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote: > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > > Is there some equivalent mechanism that lets dlloaded > > plugins dig function pointers out of the the host? Thier > > public symbol linking system is backward too from what I > > remember. > > one portable way is to pass a struct of function pointers > filled by the host to the plugin initialization function, as > done in the SuperCollider server plugin API. That doesn't really help for extensions. - Steve From larsl at users.sourceforge.net Wed May 10 09:15:25 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed May 10 09:15:35 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060510122238.GD13700@login.ecs.soton.ac.uk> References: <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> <20060510114216.GF12136@localdomain> <20060510122238.GD13700@login.ecs.soton.ac.uk> Message-ID: <1147266925.8849.9.camel@localhost> On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote: > On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote: > > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > > > Is there some equivalent mechanism that lets dlloaded > > > plugins dig function pointers out of the the host? Thier > > > public symbol linking system is backward too from what I > > > remember. > > > > one portable way is to pass a struct of function pointers > > filled by the host to the plugin initialization function, as > > done in the SuperCollider server plugin API. > > That doesn't really help for extensions. It does if the struct looks like this: struct ExtensionFunctions { struct { const char* extension_uri; void* function_pointer; }* null_terminated_function_array; }; -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060510/668f4290/attachment.bin From S.W.Harris at ecs.soton.ac.uk Wed May 10 09:38:59 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 10 09:39:26 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1147266925.8849.9.camel@localhost> References: <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> <20060510114216.GF12136@localdomain> <20060510122238.GD13700@login.ecs.soton.ac.uk> <1147266925.8849.9.camel@localhost> Message-ID: <20060510133859.GF13700@login.ecs.soton.ac.uk> On Wed, May 10, 2006 at 03:15:25PM +0200, Lars Luthman wrote: > On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote: > > On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote: > > > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > > > > Is there some equivalent mechanism that lets dlloaded > > > > plugins dig function pointers out of the the host? Thier > > > > public symbol linking system is backward too from what I > > > > remember. > > > > > > one portable way is to pass a struct of function pointers > > > filled by the host to the plugin initialization function, as > > > done in the SuperCollider server plugin API. > > > > That doesn't really help for extensions. > > It does if the struct looks like this: > > struct ExtensionFunctions { > struct { > const char* extension_uri; > void* function_pointer; > }* null_terminated_function_array; > }; OK, true, but anyway I want to avoid anything that complex until we have a real need for it. To avoid specing anything that's not quite fit for purpose. - Steve From t_w_ at freenet.de Wed May 10 09:47:46 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Wed May 10 09:47:56 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060509085953.GB25986@login.ecs.soton.ac.uk> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> Message-ID: <20060510134746.GA7350@charly.SWORD> On Tue, May 09, 2006 at 09:59:53AM +0100, Steve Harris wrote: > > But I like the idea. LV2 is less taken. Early work on the all important logo ;) http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-2/ http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-version-2-continued/ Not that I would want to push you in any direction ;) Cheers, Thorsten Wilms From dsbaikov at gmail.com Wed May 10 10:10:38 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed May 10 10:10:45 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: First trip to Europe In-Reply-To: <70a871c80605100708u363d5306k3e0cab97b1e95776@mail.gmail.com> References: <70a871c80604190639i15088fb3x30a717f07aa40513@mail.gmail.com> <44470447.8050005@bigfoot.com> <70a871c80604192331m2ad6644cj65b579e49e4e77e4@mail.gmail.com> <200604201327.11170.tech@glastonburymusic.org.uk> <20060420195102.672972e1@office> <70a871c80605100708u363d5306k3e0cab97b1e95776@mail.gmail.com> Message-ID: <70a871c80605100710l6cde62b4se20a786918155c51@mail.gmail.com> To close this thread for now. Thank you all for your kind and useful responces. However, it turned out that the main showstopper is visa. We can't get it for such a long time (a month), as it would be our first one. Things get even more complicated, since my girlfriend right now is not a student and does not have a job. They say we should build our "Shengen history" and after one-two (more - better) short and regular tours we can hope to get month-long visa anywhere we want. Taking this into account, we have to postpone our Trip to the next year and try to make two tours to shengen this year. It's a pity, since tours via travel agencies are about twice as expensive, but they are our only legal gates to europe. Moveover, the choice of the first place to visit is also restricted. We wanted to make London-Paris tour, but GB has very strict rules and rules us out. Possibly, it will be France and/or Italy as the most permissive ones. Will try to match our DreamTrip with the next LAC. Kind regards, Dmitry. From dsbaikov at gmail.com Wed May 10 12:16:04 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed May 10 12:16:10 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060510134746.GA7350@charly.SWORD> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <20060510134746.GA7350@charly.SWORD> Message-ID: <70a871c80605100916i1c64a33fpa6706aeef9bc0d0c@mail.gmail.com> LAMA - Linux(Libre) Audio Modules Architecture I hope The Dalai Lama will not object. From S.W.Harris at ecs.soton.ac.uk Wed May 10 12:19:04 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed May 10 12:19:28 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <70a871c80605100916i1c64a33fpa6706aeef9bc0d0c@mail.gmail.com> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <20060510134746.GA7350@charly.SWORD> <70a871c80605100916i1c64a33fpa6706aeef9bc0d0c@mail.gmail.com> Message-ID: <20060510161903.GH13700@login.ecs.soton.ac.uk> On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote: > LAMA - Linux(Libre) Audio Modules Architecture > > I hope The Dalai Lama will not object. Good name, but theres a well known VST plugin called Delay Lama. - Steve From drobilla at connect.carleton.ca Wed May 10 13:18:32 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed May 10 13:18:46 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <20060510114216.GF12136@localdomain> References: <20060429172520.GB1693@login.ecs.soton.ac.uk> <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> <20060510114216.GF12136@localdomain> Message-ID: <1147281512.2319.4.camel@DaveLap> On Wed, 2006-05-10 at 13:42 +0200, stefan kersten wrote: > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > > Is there some equivalent mechanism that lets dlloaded > > plugins dig function pointers out of the the host? Thier > > public symbol linking system is backward too from what I > > remember. > > one portable way is to pass a struct of function pointers > filled by the host to the plugin initialization function, as > done in the SuperCollider server plugin API. I am also a fan of explicit function pointer passing (instead of weird shared lib opening stuff that noone's been able to show will actually work) Lars' idea of making HostFeatures an array of strings /and/ void* pointers for a host to pass something (such as a function) that the plugin will need for that feature gets my vote. Simple, small change, solves the problem(s). I /really/ think there should be a nice clean mechanism for hosts to pass things to the plugin... if LADSPA2 is to be extensible, it needs this. -DR- From drobilla at connect.carleton.ca Wed May 10 13:25:26 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed May 10 13:25:41 2006 Subject: [linux-audio-dev] Todays changes to "LADSPA2" strawman In-Reply-To: <1147266925.8849.9.camel@localhost> References: <1146442381.8629.26.camel@localhost> <1146505915.9746.13.camel@DaveLap> <20060501202459.GB28107@login.ecs.soton.ac.uk> <1146516613.11055.9.camel@DaveLap> <20060501211339.GC28107@login.ecs.soton.ac.uk> <1146518643.8846.15.camel@localhost> <20060501212756.GD28107@login.ecs.soton.ac.uk> <20060508053206.GA11626@mobilat> <20060508080748.GB15609@login.ecs.soton.ac.uk> <20060510114216.GF12136@localdomain> <20060510122238.GD13700@login.ecs.soton.ac.uk> <1147266925.8849.9.camel@localhost> Message-ID: <1147281927.2319.7.camel@DaveLap> On Wed, 2006-05-10 at 15:15 +0200, Lars Luthman wrote: > On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote: > > On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote: > > > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: > > > > Is there some equivalent mechanism that lets dlloaded > > > > plugins dig function pointers out of the the host? Thier > > > > public symbol linking system is backward too from what I > > > > remember. > > > > > > one portable way is to pass a struct of function pointers > > > filled by the host to the plugin initialization function, as > > > done in the SuperCollider server plugin API. > > > > That doesn't really help for extensions. > > It does if the struct looks like this: > > struct ExtensionFunctions { > struct { > const char* extension_uri; > void* function_pointer; > }* null_terminated_function_array; > }; I don't like the function pointer specific nature of it. Simpler: struct HostFeature { const char* feature_uri; void* data; }; This allows the host to pass anything to the plugin, function pointer, struct of some useful data, pointer to some shared resource, etc. etc. -DR- From drobilla at connect.carleton.ca Wed May 10 13:46:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed May 10 13:46:51 2006 Subject: [linux-audio-dev] This weeks changes to LV2 =?ISO-8859-1?Q?=28n=E9e?= LADSPA2) strawman examples In-Reply-To: <20060510091234.GC13700@login.ecs.soton.ac.uk> References: <20060510091234.GC13700@login.ecs.soton.ac.uk> Message-ID: <1147283198.2319.11.camel@DaveLap> On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: > http://plugin.org.uk/ladspa2/ > > Changed name of the port shortname property to "symbol", which hopefully > implies more the right thing. > > Added Rate before Control and Audio port names to hopefully make thier > menaing clearer for people who may not come from a LADSPA background. > > This is just fiddling really, so I think it's starting to settle down. To say this is a nitpick is an understatement, but I like "ladspa:ControlRateInputPort" over "ladspa:InputControlRatePort". More normal and englishey. -DR- From hans at fugal.net Wed May 10 13:48:02 2006 From: hans at fugal.net (Hans Fugal) Date: Wed May 10 13:48:28 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060510161903.GH13700@login.ecs.soton.ac.uk> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <20060510134746.GA7350@charly.SWORD> <70a871c80605100916i1c64a33fpa6706aeef9bc0d0c@mail.gmail.com> <20060510161903.GH13700@login.ecs.soton.ac.uk> Message-ID: <20060510174802.GA32646@falcon.fugal.net> What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or just a cool animal that has Ls and As in the name. The Delay Lama is obviously named after the Dalai Lama, I don't think there would be any serious confusion. Maybe someone would write a Delay Lama lama plugin too. ;-) On Wed, 10 May 2006 at 17:19 +0100, Steve Harris wrote: > On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote: > > LAMA - Linux(Libre) Audio Modules Architecture > > > > I hope The Dalai Lama will not object. > > Good name, but theres a well known VST plugin called Delay Lama. > > - Steve > -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060510/8dd31aa9/attachment.bin From dominique.michel at citycable.ch Wed May 10 16:56:43 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Wed May 10 16:56:57 2006 Subject: [linux-audio-dev] surround multimedia SW on Linux In-Reply-To: <20060505084458.GA16795@bth05w.ABSp.alcatel.be> References: <20060505084458.GA16795@bth05w.ABSp.alcatel.be> Message-ID: <20060510225643.19d625ae@localhost> Le Fri, 5 May 2006 10:44:59 +0200, Alfons Adriaensen a ?crit : > I've had this request on a non-Linux list: > > Can you provide more feedback (about) ... multimedia players capable of > decoding Dolby AC3, DTS, DVD-Audio, etc. on a Linux machine? > What about software players running on a CAR-PC and surround-capable? > > I know very little about the whole field of multimedia players > for proprietary formats on Linux. Can someone fill in the gaps ? > > - which apps are available ? > - are they open-source ? > - what interfaces (ALSA, JACK, OSS, ...) do they have ? > - do they require Windoze emulation ? > - what is their maintenance state ? > - etc. > > Many thanks, > > I suppose I am not the best one to respond to that question. I mainly use xmms to play audio. http://www.xmms.org/ It can play almost anything with a plugin system. It can use Alsa, OSS, jack and other sound servers. It is a lot of plugins. As exemple, it is even a mplayer plugin that can play every format, even video, that mplayer can play. (Not sure if it is an official xmms plugin, but it work fine. http://xmmsmplayer.sourceforge.net/ ) It is a ladspa plugin too: http://www.ecs.soton.ac.uk/~njl98r/code/audio/ Mplayer alone or as xmms plugin will do a great job with many sound formats. I believe at it will be superior to many other softwares, in regard to sound quality, to play audio-DVD. If you have a compilation where the originals are coming from different sources, you will get no jump in the sound when jumping from a track to another track, and that even if the sound format is not the same. Mplayer will just do the work and get the most of the sound server. Best, Dominique From drobilla at connect.carleton.ca Thu May 11 01:59:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu May 11 01:57:26 2006 Subject: [linux-audio-dev] This weeks changes to LV2 =?ISO-8859-1?Q?=28n=E9e?= LADSPA2) strawman examples In-Reply-To: <20060510091234.GC13700@login.ecs.soton.ac.uk> References: <20060510091234.GC13700@login.ecs.soton.ac.uk> Message-ID: <1147327153.4480.5.camel@DaveLap> On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: > http://plugin.org.uk/ladspa2/ > > Changed name of the port shortname property to "symbol", which hopefully > implies more the right thing. > > Added Rate before Control and Audio port names to hopefully make thier > menaing clearer for people who may not come from a LADSPA background. > > This is just fiddling really, so I think it's starting to settle down. (I've got a working Jack host that successfully runs the example Amp plugin on Jack audio) Couple of things that need fixing: - Typo in amp.ttl line 61: "ladspa:OuputAudioRatePort" -> "ladspa:OutputAudioRatePort"X - I think ladspa:scalePoint (while a good idea) shouldn't be in the spec as it's a new feature. It belongs in the (discussed) units extension. -DR- From S.W.Harris at ecs.soton.ac.uk Thu May 11 03:23:15 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu May 11 03:23:55 2006 Subject: [linux-audio-dev] =?iso-8859-1?Q?This_?= =?iso-8859-1?Q?weeks_changes_to=09LV2_=28n=E9e?= LADSPA2) strawman examples In-Reply-To: <1147283198.2319.11.camel@DaveLap> References: <20060510091234.GC13700@login.ecs.soton.ac.uk> <1147283198.2319.11.camel@DaveLap> Message-ID: <20060511072315.GA10570@login.ecs.soton.ac.uk> On Wed, May 10, 2006 at 01:46:38 -0400, Dave Robillard wrote: > On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: > > http://plugin.org.uk/ladspa2/ > > > > Changed name of the port shortname property to "symbol", which hopefully > > implies more the right thing. > > > > Added Rate before Control and Audio port names to hopefully make thier > > menaing clearer for people who may not come from a LADSPA background. > > > > This is just fiddling really, so I think it's starting to settle down. > > To say this is a nitpick is an understatement, but I like > "ladspa:ControlRateInputPort" over "ladspa:InputControlRatePort". More > normal and englishey. If you send me a patch to the schema I'l apply it and fix the amp. Youre right, it looks better. - Steve From S.W.Harris at ecs.soton.ac.uk Thu May 11 03:29:33 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu May 11 03:29:53 2006 Subject: [linux-audio-dev] =?iso-8859-1?Q?This_?= =?iso-8859-1?Q?weeks_changes_to=09LV2_=28n=E9e?= LADSPA2) strawman examples In-Reply-To: <1147327153.4480.5.camel@DaveLap> References: <20060510091234.GC13700@login.ecs.soton.ac.uk> <1147327153.4480.5.camel@DaveLap> Message-ID: <20060511072933.GB10570@login.ecs.soton.ac.uk> On Thu, May 11, 2006 at 01:59:12 -0400, Dave Robillard wrote: > On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: > > http://plugin.org.uk/ladspa2/ > > > > Changed name of the port shortname property to "symbol", which hopefully > > implies more the right thing. > > > > Added Rate before Control and Audio port names to hopefully make thier > > menaing clearer for people who may not come from a LADSPA background. > > > > This is just fiddling really, so I think it's starting to settle down. > > (I've got a working Jack host that successfully runs the example Amp > plugin on Jack audio) > > Couple of things that need fixing: > > - Typo in amp.ttl line 61: > "ladspa:OuputAudioRatePort" > -> "ladspa:OutputAudioRatePort"X Thanks, done. > - I think ladspa:scalePoint (while a good idea) shouldn't be in the spec > as it's a new feature. It belongs in the (discussed) units extension. It's not actually a new feature, it was present in LADSPA RDF descriptions: http://plugin.org.uk/ladspa-swh/metadata/swh-scales.rdf and liblrdf. I don't think it's related to units as it deals in numerical port values, rather than real-world values. But that's splitting semantic hairs. The same goes for the classification stuff, which was the main reason users wanted RDF support from hosts for LADSPA, AFAICT. - Steve From darkeye at tyrell.hu Thu May 11 06:08:07 2006 From: darkeye at tyrell.hu (=?UTF-8?B?w4Frb3MgTWFyw7N5?=) Date: Thu May 11 06:07:21 2006 Subject: [linux-audio-dev] Edirol UA-101 support? Message-ID: <44630D07.30805@tyrell.hu> Hi, I saw this thread earlier on this list about the Edirol UA-101 external audio interface: http://lalists.stanford.edu/lad/2005/09/index.html#162 I'm trying to use the same device, but strangeley enough, it doesn't even get recognized. Looking at both the kernel sources and at the alsa-driver sources, I see the following comment: ./sound/usb/usbquirks.h: /* TODO: add Edirol UA-101 support */ how did you guys make it work? Akos From ivalladolidt at terra.es Thu May 11 10:21:29 2006 From: ivalladolidt at terra.es (Ismael Valladolid Torres) Date: Thu May 11 10:21:35 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <20060510174802.GA32646@falcon.fugal.net> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <20060510134746.GA7350@charly.SWORD> <70a871c80605100916i1c64a33fpa6706aeef9bc0d0c@mail.gmail.com> <20060510161903.GH13700@login.ecs.soton.ac.uk> <20060510174802.GA32646@falcon.fugal.net> Message-ID: <20060511142129.GD2772@spma33> Hans Fugal escribe: > What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or > just a cool animal that has Ls and As in the name. Then we would be faced against a very popular Win32 application that shouts "Winamp, it really whips the Llama's ass!" (Even though I admit I like the name!) BTW are we talking of an architecture deeply Linux-related? I mean, is it completely out of scope compiling hosts and plugins over Windows, Mac OS X or any of the BSDs? In that case I'd focus to the "libre" concept and not to the "linux" concept. My two euro cents. :) Cordially, Ismael -- Ismael Valladolid Torres OpenPGP key ID: 0xDE721AF4 [^[$B$?$S$?$S$9$_$^$;$s^[(B] Jabber ID: ivalladt@jabberes.org http://lamediahostia.blogspot.com =?iso-2022-jp?B?GyJE0hREjAGyhC?= From ivalladolidt at terra.es Thu May 11 10:24:51 2006 From: ivalladolidt at terra.es (Ismael Valladolid Torres) Date: Thu May 11 10:25:21 2006 Subject: m3u123, was Re: [linux-audio-dev] surround multimedia SW on Linux In-Reply-To: <20060510225643.19d625ae@localhost> References: <20060505084458.GA16795@bth05w.ABSp.alcatel.be> <20060510225643.19d625ae@localhost> Message-ID: <20060511142451.GE2772@spma33> Dominique Michel escribe: > It is a lot of plugins. As exemple, it is even a mplayer plugin > that can play every format, even video, that mplayer can play. (Not > sure if it is an official xmms plugin, but it work fine. > http://xmmsmplayer.sourceforge.net/ ) Even if it's not directly related to this discussion, maybe you'll find interesting a piece of software I just discovered. It's called m3u123 and allows using the console to play audio files through XMMS plug-ins, not needing an X server to be running. http://freshmeat.net/projects/m3u123/?branch_id=58817&release_id=226998 Cordially, Ismael -- Ismael Valladolid Torres OpenPGP key ID: 0xDE721AF4 [^[$B$?$S$?$S$9$_$^$;$s^[(B] Jabber ID: ivalladt@jabberes.org http://lamediahostia.blogspot.com =?iso-2022-jp?B?GyJE0hREjAGyhC?= From drobilla at connect.carleton.ca Thu May 11 14:25:44 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu May 11 14:25:53 2006 Subject: [linux-audio-dev] This weeks changes to LV2 =?ISO-8859-1?Q?=28n=E9e?= LADSPA2) strawman examples In-Reply-To: <20060511072315.GA10570@login.ecs.soton.ac.uk> References: <20060510091234.GC13700@login.ecs.soton.ac.uk> <1147283198.2319.11.camel@DaveLap> <20060511072315.GA10570@login.ecs.soton.ac.uk> Message-ID: <1147371944.8433.2.camel@DaveLap> On Thu, 2006-05-11 at 08:23 +0100, Steve Harris wrote: > On Wed, May 10, 2006 at 01:46:38 -0400, Dave Robillard wrote: > > On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: > > > http://plugin.org.uk/ladspa2/ > > > > > > Changed name of the port shortname property to "symbol", which hopefully > > > implies more the right thing. > > > > > > Added Rate before Control and Audio port names to hopefully make thier > > > menaing clearer for people who may not come from a LADSPA background. > > > > > > This is just fiddling really, so I think it's starting to settle down. > > > > To say this is a nitpick is an understatement, but I like > > "ladspa:ControlRateInputPort" over "ladspa:InputControlRatePort". More > > normal and englishey. > > If you send me a patch to the schema I'l apply it and fix the amp. Youre > right, it looks better. (attached) -DR- -------------- next part -------------- A non-text attachment was scrubbed... Name: ladspa2ttl-port-type.patch Type: text/x-patch Size: 1645 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060511/1715efe2/ladspa2ttl-port-type.bin From zenadsl6252 at zen.co.uk Fri May 12 07:04:22 2006 From: zenadsl6252 at zen.co.uk (peter) Date: Fri May 12 07:04:29 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <1147259251.18750.85.camel@mindpipe> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> <1147259251.18750.85.camel@mindpipe> Message-ID: <1147431863.6990.44.camel@dsl-62-3-104-34.zen.co.uk> On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: > On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: > > ZAP Audio Plugins > > I like this one, especially if the R. Crumb reference is intentional > hmm ZAP. not only the least offensive recursive acronym i've seen but it's also catchy, has one syllable and sounds like the ZAPP. infact, i reckon it has more bounce to the ounce. LV2 has non of the above but is also a good enough choice to my mind. =) pete. -- ====================== paugh on irc.freenode.org in #sweep, #lad kickback@users.sourceforge.net ====================== From rlrevell at joe-job.com Fri May 12 16:05:04 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri May 12 16:05:51 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <1147431863.6990.44.camel@dsl-62-3-104-34.zen.co.uk> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> <1147259251.18750.85.camel@mindpipe> <1147431863.6990.44.camel@dsl-62-3-104-34.zen.co.uk> Message-ID: <1147464305.6535.193.camel@mindpipe> On Fri, 2006-05-12 at 12:04 +0100, peter wrote: > On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: > > On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: > > > ZAP Audio Plugins > > > > I like this one, especially if the R. Crumb reference is intentional > > > > hmm ZAP. not only the least offensive recursive acronym i've seen but > it's Why was 'peep' offensive? urbandictionary was of no help. > also catchy, has one syllable and sounds like the ZAPP. What's ZAPP? > infact, i > reckon it > has more bounce to the ounce. > LV2 has non of the above but is also a good enough choice to my mind. > =) > > pete. From zenadsl6252 at zen.co.uk Fri May 12 17:39:37 2006 From: zenadsl6252 at zen.co.uk (pete) Date: Fri May 12 17:39:52 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <1147464305.6535.193.camel@mindpipe> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> <1147259251.18750.85.camel@mindpipe> <1147431863.6990.44.camel@dsl-62-3-104-34.zen.co.uk> <1147464305.6535.193.camel@mindpipe> Message-ID: <44650099.8090809@zen.co.uk> Lee Revell wrote: > On Fri, 2006-05-12 at 12:04 +0100, peter wrote: > >> On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: >> >>> On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: >>> >>>> ZAP Audio Plugins >>>> >>> I like this one, especially if the R. Crumb reference is intentional >>> >>> >> hmm ZAP. not only the least offensive recursive acronym i've seen but >> it's >> > > Why was 'peep' offensive? urbandictionary was of no help. different kind of offensive. recursive acro's are often contrived and stretched to fit. peep isn't SO bad and it's even palindromic if you go in for that sort of thing but ZAP just seems to have a lot going for it where peep seems a bit laboured. >> also catchy, has one syllable and sounds like the ZAPP. >> > > What's ZAPP? > 70-80's electro funk band. featuring a characteristic use of vocoders. more bounce to the ounce is probably their best known track. (features in la haine in the breakdancing scene if you've seen that. ) so uhm.. i like ZAPP and also like Z.A.P. the idea of a zap vocoder plugin seems a fitting tribute to the vocoder pioneers. not exactly relevant but i liked it enough to wade in on its behalf. :) >> infact, i >> reckon it >> has more bounce to the ounce. >> LV2 has non of the above but is also a good enough choice to my mind. >> =) pete. From drobilla at connect.carleton.ca Fri May 12 21:12:25 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri May 12 21:12:37 2006 Subject: [linux-audio-dev] LADSPA 2 name In-Reply-To: <44650099.8090809@zen.co.uk> References: <20060508172822.GB7353@charly.SWORD> <1147112443.8851.0.camel@localhost> <20060508192946.GA11274@slinkp.com> <20060509085953.GB25986@login.ecs.soton.ac.uk> <873bfipiny.fsf@esben-stien.name> <20060510075512.GA13700@login.ecs.soton.ac.uk> <87vesenioe.fsf@esben-stien.name> <1147259251.18750.85.camel@mindpipe> <1147431863.6990.44.camel@dsl-62-3-104-34.zen.co.uk> <1147464305.6535.193.camel@mindpipe> <44650099.8090809@zen.co.uk> Message-ID: <1147482746.30798.0.camel@DaveLap> On Fri, 2006-05-12 at 22:39 +0100, pete wrote: > Lee Revell wrote: > > On Fri, 2006-05-12 at 12:04 +0100, peter wrote: > > > >> On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: > >> > >>> On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: > >>> > >>>> ZAP Audio Plugins > >>>> > >>> I like this one, especially if the R. Crumb reference is intentional > >>> > >>> > >> hmm ZAP. not only the least offensive recursive acronym i've seen but > >> it's > >> > > > > Why was 'peep' offensive? urbandictionary was of no help. > different kind of offensive. recursive acro's are often contrived and stretched to fit. > peep isn't SO bad and it's even palindromic if you go in for that sort of thing but ZAP > just seems to have a lot going for it where peep seems a bit laboured. I don't like ZAP at all. Sounds silly and childish. -DR- From dlphillips at woh.rr.com Sat May 13 11:51:24 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sat May 13 11:47:15 2006 Subject: [linux-audio-dev] [ANN] Bol Processor going Open Source! In-Reply-To: References: Message-ID: <4466007C.6020707@woh.rr.com> Anthony Kozar wrote: >Bernard Bel and I are very happy to announce to you that a powerful tool for >computer-aided composition using Csound or Midi -- the Bol Processor -- is >being reborn as open source software! While the software only runs on >Macintosh computers at this time, we are hoping that some savvy Linux >developers with porting experience will be interested in joining the >project. > >Thanks! (And please email me directly if you want to see the source code in >a more Linux-friendly format :) > > Hi Anthony: Wonderful news ! I've wondered about the Bol Processor for many years, now I just might get the chance to see it in action on Linux. :) Many thanks to you and to Prof. Bell for releasing this software as an open-source project. I sincerely hope it sees acceptance in the larger Linux audio world. Best, dp From dlphillips at woh.rr.com Sat May 13 11:57:34 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sat May 13 11:53:33 2006 Subject: [linux-audio-dev] stuff I've done In-Reply-To: References: Message-ID: <446601EE.2080809@woh.rr.com> Bradford Garton wrote: > I've just put on-line a whole lot of work I've done; papers, pieces, > software, etc. Here's the link for the 2-3 people (beyond my > immediate family) who might be interested: > > http://music.columbia.edu/~brad/ > > There's a fair amount of unix/linux work scattered throughout, > including the big "My Music Book" thing I did a few years ago. Hi Brad: Many thanks for placing this work on-line and making it freely available. For those of you who don't know: Brad Garton is a mover & shaker with roots in Cmix and other computer music communities. He's been involved in the scene for a long while, and I consider anything he's done to be worth looking at. And I'll always be grateful for his many varieties of Looching. :) Best, dp From fons.adriaensen at skynet.be Sat May 13 12:37:46 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat May 13 12:30:05 2006 Subject: [linux-audio-dev] [ANN] New release of Aeolus, updates Message-ID: <20060513163746.GB4749@linux-1> Hello all, The long announced new release of Aeolus is finally available. Version 0.6.6 is almost a complete rewrite of the previous official release, 0.3.1 (a lot happened in bewteen). This should still be considered a beta release - no doubt some nasty bugs will be uncovered when this version is used more widely. This release has been reported to build and work 'out of the box' on a 64-bit system, but 64-bit support is still experimental. At the same time, jaaa, japa, jace and jdelay have been updated to use the new shared libraries. So support for the older libs and everything using them will stop. There's also one small new thing, jnoise. This is a simple command line JACK app producing accurate white and pink noise. As always, everyhting is to be found at http://users.skynet.be/solaris/linuxaudio There are also some new Aeolus demo files by Bert Visser, as heard at the LAC2006 demo. Enjoy ! -- FA Follie! Follie! Delirio vano e' questo! From music at chemie.fu-berlin.de Sun May 14 08:19:16 2006 From: music at chemie.fu-berlin.de (Michael Iber) Date: Sun May 14 08:19:05 2006 Subject: [linux-audio-dev] LAC-Konzertreport auf SWR2 15.5. 23h (German only) Message-ID: <44672044.8090300@chemie.fu-berlin.de> Hi lists, my little report on the lac-concerts and some other subjects of the lac in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik Magazin at 23h. Michael From b0ef at esben-stien.name Mon May 15 10:28:34 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon May 15 08:30:46 2006 Subject: [linux-audio-dev] Re: Drum synth In-Reply-To: (Juhana Sadeharju's message of "Thu, 23 Sep 2004 19:01:52 +0300") References: Message-ID: <87u07rweel.fsf@esben-stien.name> Juhana Sadeharju writes: > ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/ This link is dead. You have an alternate one?;) -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From b0ef at esben-stien.name Mon May 15 10:34:05 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon May 15 08:36:18 2006 Subject: [linux-audio-dev] Drum synth In-Reply-To: <20040921113055.M67689@pawfal.org> (Dave Griffiths's message of "Tue, 21 Sep 2004 12:37:17 +0100") References: <70a871c8040918110467a63b46@mail.gmail.com> <414C9726.4030803@chriswareham.demon.co.uk> <20040918213508.GA21918@dyne.org> <70a871c804091814513509c232@mail.gmail.com> <20040921081247.GB24415@hortus-mechanicus.net> <20040921113055.M67689@pawfal.org> Message-ID: <87lkt3we5e.fsf@esben-stien.name> "Dave Griffiths" writes: > http://devdsp.net/index.pl?main=noizefarm_full&bid=1327 > http://devdsp.net/index.pl?main=noizefarm_full&bid=1449 It would be nice if you could dig up again these links as they are now broken;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From b0ef at esben-stien.name Mon May 15 10:47:07 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon May 15 08:49:42 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <41629FF3.5050205@teleset.com.co> (Andres Cabrera's message of "Tue, 05 Oct 2004 09:21:55 -0400") References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200410041611.07827.jbd@cableone.net> <4161F1AB.9060700@bright.net> <41629FF3.5050205@teleset.com.co> Message-ID: <87d5efwdjo.fsf@esben-stien.name> Andres Cabrera writes: > I'll refocus and try to get it working in realtime Any luck with this? -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From b0ef at esben-stien.name Mon May 15 10:50:02 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon May 15 08:52:16 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <200410041611.07827.jbd@cableone.net> (Downer's message of "Mon, 4 Oct 2004 16:11:07 -0700") References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200410041611.07827.jbd@cableone.net> Message-ID: <878xp3wdet.fsf@esben-stien.name> Downer writes: > Baudline This is now released as GPL software, though not available for download, or so it seems. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From koloska at voiceinterconnect.de Mon May 15 09:17:24 2006 From: koloska at voiceinterconnect.de (Uwe Koloska) Date: Mon May 15 09:15:07 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <878xp3wdet.fsf@esben-stien.name> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200410041611.07827.jbd@cableone.net> <878xp3wdet.fsf@esben-stien.name> Message-ID: <200605151517.24465.koloska@voiceinterconnect.de> Am Montag, 15. Mai 2006 16:50 schrieb Esben Stien: > [Baudline] is now released as GPL software, though not available for > download, or so it seems. Really??? The website doesn't say so ... Uwe From b0ef at esben-stien.name Mon May 15 14:31:28 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Mon May 15 12:33:41 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <200605151517.24465.koloska@voiceinterconnect.de> (Uwe Koloska's message of "Mon, 15 May 2006 15:17:24 +0200") References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200410041611.07827.jbd@cableone.net> <878xp3wdet.fsf@esben-stien.name> <200605151517.24465.koloska@voiceinterconnect.de> Message-ID: <87ves7uolb.fsf@esben-stien.name> Uwe Koloska writes: > The website doesn't say so ... Yes, it does. If you navigate to the download section and then follow the source link. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From koloska at voiceinterconnect.de Mon May 15 13:02:53 2006 From: koloska at voiceinterconnect.de (Uwe Koloska) Date: Mon May 15 13:00:30 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <87ves7uolb.fsf@esben-stien.name> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200605151517.24465.koloska@voiceinterconnect.de> <87ves7uolb.fsf@esben-stien.name> Message-ID: <200605151902.53745.koloska@voiceinterconnect.de> Am Montag, 15. Mai 2006 20:31 schrieb Esben Stien: > Uwe Koloska writes: > > The website doesn't say so ... > > Yes, it does. If you navigate to the download section and then follow > the source link. Ok, but I think GPL and purchase is a contradiction, isn't it? Uwe From rlrevell at joe-job.com Mon May 15 13:15:01 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon May 15 13:15:15 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <200605151902.53745.koloska@voiceinterconnect.de> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200605151517.24465.koloska@voiceinterconnect.de> <87ves7uolb.fsf@esben-stien.name> <200605151902.53745.koloska@voiceinterconnect.de> Message-ID: <1147713302.27252.274.camel@mindpipe> On Mon, 2006-05-15 at 19:02 +0200, Uwe Koloska wrote: > Am Montag, 15. Mai 2006 20:31 schrieb Esben Stien: > > Uwe Koloska writes: > > > The website doesn't say so ... > > > > Yes, it does. If you navigate to the download section and then follow > > the source link. > > Ok, but I think GPL and purchase is a contradiction, isn't it? > No, it's perfectly legal to sell GPL software. Here's the contradiction: License Agreement: * This software is free and it comes with no warranty. * We are not liable for any damage caused by the use of this product. * You are not allowed to distribute this software. * You are not allowed to reverse engineer this software. * By downloading the baudline .tar package you agree to the terms of our license agreement. * If you desire a warranty on this product and you wish to purchase a support contract then please contact us. GPL does not allow additional restrictions. Lee From koloska at voiceinterconnect.de Mon May 15 13:29:54 2006 From: koloska at voiceinterconnect.de (Uwe Koloska) Date: Mon May 15 13:27:33 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <1147713302.27252.274.camel@mindpipe> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200605151902.53745.koloska@voiceinterconnect.de> <1147713302.27252.274.camel@mindpipe> Message-ID: <200605151929.55005.koloska@voiceinterconnect.de> Am Montag, 15. Mai 2006 19:15 schrieb Lee Revell: > > Ok, but I think GPL and purchase is a contradiction, isn't it? I have had better said: GPL and purchasing the source is a contradiction, isn't it? > No, it's perfectly legal to sell GPL software. Yes, but not the sourcecode. You can charge for handling and don't have to provide a direct download, but you are not allowed to purchase the code. And if the code is public anyone can give it away for free. So, if they really have chosen to make the code available under the terms of the GPL (and noone has forced them to do) they must follow the license and can't make additional restrictions as you have stated. Uwe From rlrevell at joe-job.com Mon May 15 13:33:13 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon May 15 13:33:22 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <200605151929.55005.koloska@voiceinterconnect.de> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200605151902.53745.koloska@voiceinterconnect.de> <1147713302.27252.274.camel@mindpipe> <200605151929.55005.koloska@voiceinterconnect.de> Message-ID: <1147714394.27252.279.camel@mindpipe> On Mon, 2006-05-15 at 19:29 +0200, Uwe Koloska wrote: > Am Montag, 15. Mai 2006 19:15 schrieb Lee Revell: > > > Ok, but I think GPL and purchase is a contradiction, isn't it? > > I have had better said: GPL and purchasing the source is a contradiction, > isn't it? > > > No, it's perfectly legal to sell GPL software. > > Yes, but not the sourcecode. You can charge for handling and don't have to > provide a direct download, but you are not allowed to purchase the code. And > if the code is public anyone can give it away for free. > > So, if they really have chosen to make the code available under the terms of > the GPL (and noone has forced them to do) they must follow the license and > can't make additional restrictions as you have stated. > Actually, you can sell the sourcecode, but it doesn't make sense to because you also have to provide it for free. > Uwe > From ce at christeck.de Mon May 15 17:31:00 2006 From: ce at christeck.de (Christoph Eckert) Date: Mon May 15 17:29:24 2006 Subject: [linux-audio-dev] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <44672044.8090300@chemie.fu-berlin.de> References: <44672044.8090300@chemie.fu-berlin.de> Message-ID: <200605152331.01685.ce@christeck.de> Hi, > my little report on the lac-concerts and some other subjects of the > lac in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik > Magazin at 23h. recording... :) . Best regards ce From fons.adriaensen at skynet.be Mon May 15 17:55:30 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon May 15 17:48:03 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <200605152331.01685.ce@christeck.de> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> Message-ID: <20060515215530.GA4970@linux-1> On Mon, May 15, 2006 at 11:31:00PM +0200, Christoph Eckert wrote: > recording... :) . + oggenc + ftp + mail LAD ??? :-) :-) :-) -- FA Follie! Follie! Delirio vano e' questo! From ce at christeck.de Mon May 15 18:06:24 2006 From: ce at christeck.de (Christoph Eckert) Date: Mon May 15 18:04:50 2006 Subject: [linux-audio-dev] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <20060515215530.GA4970@linux-1> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> <20060515215530.GA4970@linux-1> Message-ID: <200605160006.25107.ce@christeck.de> Hi, > + oggenc + ftp + mail LAD ??? :-) :-) :-) of course, but not tonight :) . Gn8, ce From ce at christeck.de Mon May 15 18:37:03 2006 From: ce at christeck.de (Christoph Eckert) Date: Mon May 15 18:35:24 2006 Subject: [linux-audio-dev] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <20060515215530.GA4970@linux-1> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> <20060515215530.GA4970@linux-1> Message-ID: <200605160037.06714.ce@christeck.de> Hi, I guess it is a legal issue posting the recording to the public. Any idea via PM is appreciated :) . Best regards, ce From music at chemie.fu-berlin.de Tue May 16 04:31:38 2006 From: music at chemie.fu-berlin.de (Michael Iber) Date: Tue May 16 04:32:01 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <200605152331.01685.ce@christeck.de> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> Message-ID: <44698DEA.7030506@chemie.fu-berlin.de> Hi all, unfortunately, for legal reasons it is not possible to make the audio-data public. I discussed this with the broadcast station before, and their lawyers said definitely: no. For all of you capable of reading a little bit of German: see my manuscript attached. Goetz may put it on the LAC-Website, too. (Thank you, Goetz) Best, Michael Christoph Eckert schrieb: > Hi, > > >> my little report on the lac-concerts and some other subjects of the >> lac in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik >> Magazin at 23h. > > recording... :) . > > > Best regards > > > ce > > -------------- next part -------------- A non-text attachment was scrubbed... Name: lac2006_swr.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060516/8091fafb/lac2006_swr-0001.doc From arnold.krille at gmail.com Tue May 16 06:32:29 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Tue May 16 06:32:35 2006 Subject: [linux-audio-dev] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <200605160037.06714.ce@christeck.de> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> <20060515215530.GA4970@linux-1> <200605160037.06714.ce@christeck.de> Message-ID: <2def88b80605160332j37f8d5f1v5c0a60da7e36266d@mail.gmail.com> 2006/5/16, Christoph Eckert : > I guess it is a legal issue posting the recording to the public. > Any idea via PM is appreciated :) . Well, german law allows private copies from friend to friend. (Regardless what the music-industry is telling you.) Only thing forbidden is to use tools to get around copy-protections. And as the broadcast was in public radio everyone could have made his own recording and so it is also allowed to get a copy from a "friend". All the germans have even payed GEMA-fees already if we burn our copy to cd... So sending the ftp/http link to friends is the key. Arnold PS: Could I get a copy of this recording? -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From fbar at footils.org Tue May 16 06:52:12 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue May 16 06:52:26 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <44698DEA.7030506@chemie.fu-berlin.de> References: <44672044.8090300@chemie.fu-berlin.de> <200605152331.01685.ce@christeck.de> <44698DEA.7030506@chemie.fu-berlin.de> Message-ID: <20060516105212.GK24735@fliwatut.scifi> Hallo, Michael Iber hat gesagt: // Michael Iber wrote: > unfortunately, for legal reasons it is not possible to make the > audio-data public. I discussed this with the broadcast station before, > and their lawyers said definitely: no. The background is GEMA. Working for the website of a public radio in Germany myself (www.dradio.de) I know these issues a bit. We have a very big audio on demand section on our website (and Ogg streaming btw.) but we have to or at least try hard to filter out everything that is music or radio play. Only words allowed. Of course the authors get paid additional money if their work is also offered as a download, which is another issue to consider. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From andres at geminiflux.com Mon May 15 11:59:25 2006 From: andres at geminiflux.com (Andres Cabrera) Date: Tue May 16 07:41:16 2006 Subject: [linux-audio-dev] 3D fft analysis program In-Reply-To: <87d5efwdjo.fsf@esben-stien.name> References: <200410031601.i93G1GqJ013451@roar.music.columbia.edu> <200410041611.07827.jbd@cableone.net> <4161F1AB.9060700@bright.net> <41629FF3.5050205@teleset.com.co> <87d5efwdjo.fsf@esben-stien.name> Message-ID: <1147708765.4734.12.camel@dynamic-ip-697912812.cable.net.co> Hi Esben, > Any luck with this? Not really.... I dropped the idea, having found other similar things, though I don't remembre now which, and my mail achives don't go that far back... Cheers, Andr?s On Mon, 2006-05-15 at 16:47 +0200, Esben Stien wrote: > Andres Cabrera writes: > > > I'll refocus and try to get it working in realtime > > Any luck with this? > > -- > Esben Stien is b0ef@e s a > http://www. s t n m > irc://irc. b - i . e/%23contact > [sip|iax]: e e > jid:b0ef@ n n > > > � From ce at christeck.de Tue May 16 13:34:36 2006 From: ce at christeck.de (Christoph Eckert) Date: Tue May 16 13:32:39 2006 Subject: [linux-audio-dev] Re: LAC-Konzertreport auf SWR2 15.5. 23h (German only) In-Reply-To: <2def88b80605160332j37f8d5f1v5c0a60da7e36266d@mail.gmail.com> References: <44672044.8090300@chemie.fu-berlin.de> <200605160037.06714.ce@christeck.de> <2def88b80605160332j37f8d5f1v5c0a60da7e36266d@mail.gmail.com> Message-ID: <200605161934.36567.ce@christeck.de> Hi, > Well, german law allows private copies from friend to friend. > (Regardless what the music-industry is telling you.) Only thing > forbidden is to use tools to get around copy-protections. > > And as the broadcast was in public radio everyone could have made his > own recording and so it is also allowed to get a copy from a > "friend". All the germans have even payed GEMA-fees already if we > burn our copy to cd... > > So sending the ftp/http link to friends is the key. well, but who is your friend and who is the judge... > PS: Could I get a copy of this recording? "Et ne nos inducas in tentationem..." :) Best regards ce From aaron at akjmusic.com Tue May 16 14:42:10 2006 From: aaron at akjmusic.com (Aaron Krister Johnson) Date: Tue May 16 14:42:35 2006 Subject: [linux-audio-dev] fst problems Message-ID: <200605161342.10207.aaron@akjmusic.com> Hi, I've recently compiled fst-1.7 on a Slackware 10.1 system. Wine version is wine-20050310. I get the following error when I issue this command to try the "Kontakt2Demo.dll": root@aaron:~/fst-1.7# ./fst /home/akj/Desktop/Kontakt2Demo.dll and this is what happens: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x40fffd80 in 32-bit code (0x4000a753). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0000 EIP:4000a753 ESP:40e5f8e4 EBP:40e5f9dc EFLAGS:00210202( - 00 - -RI1) EAX:40fffd80 EBX:40015ff8 ECX:00000000 EDX:40e5f90c ESI:40e5fa24 EDI:40015cc0 Stack dump: 0x40e5f8e4: 00000000 00000000 00000000 00000000 0x40e5f8f4: 00000302 40166d20 7800305c 78003058 0x40e5f904: 000041ed 00000000 00000000 00000000 0x40e5f914: 00000000 00000000 00000000 00000238 0x40e5f924: 00000000 00020000 00000001 00000000 0x40e5f934: 446a1bb0 00000000 443fcf84 00000000 Backtrace: =>1 0x4000a753 _dl_catch_error in ld-linux.so.2 (0x40e5f9dc) 2 0x401672c1 _dlerror_run in libdl.so.2 (0x40e5fa0c) 3 0x40166cf1 GLIBC_2 in libdl.so.2 (0x40e5fa3c) 4 0x400335cc wine_dlopen in libwine.so.1 (0x40e5fa58) 5 0x40032d17 wine_get_es in libwine.so.1 (0x40e5fa88) 6 0x400332b8 wine_dll_load in libwine.so.1 (0x40e5fab4) 7 0x401a92bf in ntdll (+0x292bf) (0x40e5fd04) 8 0x401a9c10 in ntdll (+0x29c10) (0x40e5fd9c) 9 0x401a75c7 call_dll_entry_point in ntdll (0x40e5fe44) 10 0x401a7b27 call_dll_entry_point in ntdll (0x40e5fe78) 11 0x401aa758 LdrInitializeThunk in ntdll (0x40e5ff20) 12 0x404e7f8b in kernel32 (+0x47f8b) (0x40e5fff4) 13 0x40033cbd wine_switch_to_stack in libwine.so.1 (0x00000000) 0x4000a753 _dl_catch_error+0x43 in ld-linux.so.2: movl 0x0(%eax),%ecx Wine-dbg> Any thoughts? Best, Aaron. From khremeviuc at yahoo.com Wed May 17 02:08:18 2006 From: khremeviuc at yahoo.com (Kevin Hremeviuc) Date: Wed May 17 02:08:26 2006 Subject: [linux-audio-dev] Alsa sequencer - starting a track in the middle and looping Message-ID: <20060517060818.28500.qmail@web60713.mail.yahoo.com> Hi all, Trying to implement starting the playing of a track at a user defined cursor position (not at the start). Also trying to implement looping. Anybody got any info or code snippets that could help (c or c++ - not too complicated though and without too much tangential code). I am sorry but I find the alsa documentation not very helpful. The documentation of the concept of the sequencer is either out of date or in another case just enough to get people going. The api documentation is just woe-ful. I have had to constantly look at other peoples' code (and try to understand what they were up to). Have I missed finding some top notch documentation? Java based gui programme using the java native interface (JNI) and a c library to access alsa sequencer. Java allows for a high level of platform independence. The c library, accessed via the JNI, can be re-written to interface with various libraries like portmidi to allow for full platform independence (with some caveats no doubt). The concept is the usual song has tracks, which have parts which have events. Each track also has a global part for automation data (volume, pan etc). Each track has 64 patterns (parts). The sequencer allows for a looping audition mode (using the selected pattern from each track ). Song mode allows these patterns to be inserted on a per track basis as required to create an arrangement. At the moment the sequencer ends up being very jack and linux oriented in that many jack audio applications are started up and managed by the application itself. I am not sure how this would translate onto windows. Also because many independent jack applications are being run things like jackrack also need to be run (for effects) and jack connections managed. If there is a windows equivalent maybe someone could let me know (I haven't touched windows in years except at uni and in the workplace). I finished uni at the end of last year (after many years of working full time and studying at half load, then finally studying full time) and have had some time on my hands. I have now fully revised a lot of stuff for getting a job (2 interviews in 5 months - so it's pretty slow going), built a business web app using java JSPs, java tag libraries, struts and JDO JPox for my wife and now I am working on some old code to build a midi sequencer based around the way I like to make music (patterns and automation). Sorry about the above waffle but it explains why have subscribed to this list for quite a few years and never contributed anything. Thanks Kev Send instant messages to your online friends http://uk.messenger.yahoo.com From aaron at akjmusic.com Wed May 17 14:35:28 2006 From: aaron at akjmusic.com (Aaron Krister Johnson) Date: Wed May 17 14:36:05 2006 Subject: [linux-audio-dev] more questions on FST Message-ID: <200605171335.28231.aaron@akjmusic.com> Hi all- I tried fst-1.7 under the latest version of wine on my Slackware 10.1 system--no luck still. I'm beginning to think that fst is not playing nice with glibc-2.3.4 Can someone who has used Kontakt under Linux share the output of /lib/libc.so.6 here with me so I can compare? Also, if glibc is indeed the problem, is there smething I can change in the fst code that would make it work with my current version if I can show debugging info--I prefer not to go through the headache of overhauling my entire system if there's a uick fix in fst code instead. Another question--barring that, if I do replace glibc, will I have to recompile my kernel, wine, etc? Best, Aaron. From rlrevell at joe-job.com Wed May 17 15:40:44 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed May 17 15:41:04 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <200605171335.28231.aaron@akjmusic.com> References: <200605171335.28231.aaron@akjmusic.com> Message-ID: <1147894844.2473.5.camel@mindpipe> On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: > Another question--barring that, if I do replace glibc, will I have to > recompile my kernel, wine, etc? You would have to recompile EVERYTHING. Replacing glibc is major surgery. It's best to just upgrade to a newer distro. Lee From torbenh at gmx.de Wed May 17 15:43:44 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed May 17 15:46:37 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <1147894844.2473.5.camel@mindpipe> References: <200605171335.28231.aaron@akjmusic.com> <1147894844.2473.5.camel@mindpipe> Message-ID: <20060517194344.GA17048@mobilat> On Wed, May 17, 2006 at 03:40:44PM -0400, Lee Revell wrote: > On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: > > Another question--barring that, if I do replace glibc, will I have to > > recompile my kernel, wine, etc? > > You would have to recompile EVERYTHING. Replacing glibc is major > surgery. thats not true lee. i switched glibcs around when debugging fst. just make sure you have the old version around, and a boot cd so that you can recover from failure. also make sure you enable tls. and have a 2.6.x kernel... > > It's best to just upgrade to a newer distro. > > Lee > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From dominique.michel at citycable.ch Wed May 17 16:08:32 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Wed May 17 16:08:46 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <1147894844.2473.5.camel@mindpipe> References: <200605171335.28231.aaron@akjmusic.com> <1147894844.2473.5.camel@mindpipe> Message-ID: <20060517220832.3d10f3dc@localhost> Le Wed, 17 May 2006 15:40:44 -0400, Lee Revell a ?crit : > On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: > > Another question--barring that, if I do replace glibc, will I have to > > recompile my kernel, wine, etc? > > You would have to recompile EVERYTHING. Replacing glibc is major > surgery. > > It's best to just upgrade to a newer distro. > > Lee > It is a complicated matter. The system must be consistent. For that, you can have a program compiled against glib.xxx compiled against glib.yyy. It should work but is not optimal. If you want to replace glib.yyy by glib.xxx, it is a long process. You can look at http://www.gentoo.org/doc/en/gcc-upgrading.xml to get an id?e. The advantage of doing that is at it is no need to reinstall everithing from the scratch and will it will keep even your preferences, but in case of problem, you can get a completly broken system. Ciao, Dominique From rlrevell at joe-job.com Wed May 17 18:10:38 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed May 17 18:10:49 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <20060517194344.GA17048@mobilat> References: <200605171335.28231.aaron@akjmusic.com> <1147894844.2473.5.camel@mindpipe> <20060517194344.GA17048@mobilat> Message-ID: <1147903839.10153.14.camel@mindpipe> On Wed, 2006-05-17 at 21:43 +0200, torbenh@gmx.de wrote: > On Wed, May 17, 2006 at 03:40:44PM -0400, Lee Revell wrote: > > On Wed, 2006-05-17 at 13:35 -0500, Aaron Krister Johnson wrote: > > > Another question--barring that, if I do replace glibc, will I have to > > > recompile my kernel, wine, etc? > > > > You would have to recompile EVERYTHING. Replacing glibc is major > > surgery. > > thats not true lee. > i switched glibcs around when debugging fst. > just make sure you have the old version around, and a boot cd so that you > can recover from failure. > > also make sure you enable tls. > and have a 2.6.x kernel... I guess it depends on the distro. There was a recent report of someone trying to upgrade glibc and they ended up having to reinstall. I would think with a source based distro you'd have to recompile quite a bit, but I haven't used one myself. Does FST definitely require NPTL? Lee From cuse at users.sourceforge.net Thu May 18 11:59:15 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Thu May 18 11:59:09 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <1147903839.10153.14.camel@mindpipe> References: <200605171335.28231.aaron@akjmusic.com> <20060517194344.GA17048@mobilat> <1147903839.10153.14.camel@mindpipe> Message-ID: <200605181759.17535.cuse@users.sourceforge.net> Es geschah am Thursday, 18. May 2006 00:10 als Lee Revell schrieb: > Does FST definitely require NPTL? That's a big fat YES! CU Christian From paul at linuxaudiosystems.com Thu May 18 12:01:57 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu May 18 12:02:05 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <200605181759.17535.cuse@users.sourceforge.net> References: <200605171335.28231.aaron@akjmusic.com> <20060517194344.GA17048@mobilat> <1147903839.10153.14.camel@mindpipe> <200605181759.17535.cuse@users.sourceforge.net> Message-ID: <1147968117.17100.81.camel@localhost.localdomain> On Thu, 2006-05-18 at 17:59 +0200, Christian Schoenebeck wrote: > Es geschah am Thursday, 18. May 2006 00:10 als Lee Revell schrieb: > > Does FST definitely require NPTL? > > That's a big fat YES! put differently: WINE requires NPTL to function adequately with multithreaded applications. --p From gene.heskett at verizon.net Thu May 18 23:19:58 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu May 18 23:20:10 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. Message-ID: <446D395E.6030002@verizon.net> Greetings everybody, this time I'm temporarily a Yupee, as in upstate michigan. I brought a laptop along, with linux on it, FC5, 386 version on an AMD64 turion in an HP dv5320us laptop.. The audio chipset in this is, from an lspci -v: 0:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 02) Subsystem: Hewlett-Packard Company Unknown device 30a4 Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 11 Memory at c0003400 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- The problem is that anything that requires it to handle a full duplex audio stream falls over very quickly. Skype in 10 seconds, ekiga even quicker, and in audacity, it will record great, and it will playback what it records great, but if you ask it to play as it records like one would do for overdubs and such, the sound in the headphones represents only that amount of the audio that may have hit the rails in the a-d, very chopped up, and often sounding like an echo thats cut into 2ms pieces and spread out over the next 30 seconds. Is there any known cure for this other than sueing HP for such a shitty piece of hardware that cost me about $1399 at CC? That of course will be a waste of time because their warranty shop says any and all warranties on it were null and void the instant I put a linux dvd in the drive. Any hints that result in getting something like skype or ekiga working will be applied with many profuse thanks offered. -- Cheers, Gene From rlrevell at joe-job.com Thu May 18 23:31:45 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu May 18 23:31:54 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446D395E.6030002@verizon.net> References: <446D395E.6030002@verizon.net> Message-ID: <1148009506.32630.57.camel@mindpipe> On Thu, 2006-05-18 at 22:19 -0500, Gene Heskett wrote: > Any hints that result in getting something like skype or ekiga > working > will be applied with many profuse thanks offered. > What ALSA version (/proc/asound/version)? Which driver is being used? Any change if you run the apps with "aoss"? e.g. "aoss ./skype" Lee From gene.heskett at verizon.net Fri May 19 00:12:01 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri May 19 00:12:24 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <1148009506.32630.57.camel@mindpipe> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> Message-ID: <446D4591.1030603@verizon.net> Lee Revell wrote: > On Thu, 2006-05-18 at 22:19 -0500, Gene Heskett wrote: >> Any hints that result in getting something like skype or ekiga >> working >> will be applied with many profuse thanks offered. >> > > What ALSA version (/proc/asound/version)? > root@diablo skype]# cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC). > Which driver is being used? From an lsmod: snd_atiixp_modem 15433 1 snd_seq_dummy 3781 0 snd_atiixp 19157 2 snd_ac97_codec 83937 2 snd_atiixp_modem,snd_atiixp snd_ac97_bus 2497 1 snd_ac97_codec snd_seq_oss 28993 0 snd_seq_midi_event 7105 1 snd_seq_oss snd_seq 47153 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 8909 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 45009 0 snd_mixer_oss 16449 2 snd_pcm_oss snd_pcm 76869 4 snd_atiixp_modem,snd_atiixp,snd_ac97_codec,snd_pcm_oss snd_timer 22597 2 snd_seq,snd_pcm snd 50501 14 snd_atiixp_modem,snd_atiixp,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 9377 2 snd snd_page_alloc 10441 3 snd_atiixp_modem,snd_atiixp,snd_pcm > Any change if you run the apps with "aoss"? e.g. "aoss ./skype" > > Lee > > aoss apparently not installed: [root@diablo skype]# aoss ./skype bash: aoss: command not found Note that skype is the only oss program, but that ekiga and audacity are similarly plagued. I can find no 'aoss' containing file with yumex. -- Cheers, Gene From t_w_ at freenet.de Fri May 19 10:06:01 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Fri May 19 10:06:09 2006 Subject: [linux-audio-dev] LV2 Logo again Message-ID: <20060519140601.GA7342@charly.SWORD> Hi! So LV2 will be the name by benevolent dictator descision :) More work on the logo: http://affenbande.org/~thorwil/wordpress/2006/05/19/lv2-5/ It's still a bit rough, so a few things might not be lined up perfectly, line width may be slightly inconsistent, but it should be good enough to get the idea and judge the overall shapes. I tried to bring in the idea of things connecting to build a whole. A puzzle in a way. I would like to hear of preferences (2 picks are better than 1), dislikes, and pointers to what could be improved with a specific variation. Cheers, Thorsten Wilms From cannam at all-day-breakfast.com Fri May 19 10:27:15 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Fri May 19 10:26:21 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis Message-ID: <200605191527.15092.cannam@all-day-breakfast.com> Announcing Sonic Visualiser, an application for viewing and analysing the contents of music audio files. http://www.sonicvisualiser.org/ Sonic Visualiser contains advanced waveform and spectrogram viewers, as well as editors for many sorts of audio annotations. Besides visualisation, it can make and play selections based on the locations of automatically detected features, seamlessly loop playback of single or multiple noncontiguous regions, synthesise annotations for playback, and slow down playback while retaining display synchronisation. Sonic Visualiser also introduces the Vamp plugin API, for plugins that extract descriptive or analytical data from audio. Vamp plugins for onset, pitch and note detection using the Aubio library are available, as well as plugins for tempo tracking, chromagram analysis, constant-Q spectrogram, spectral centroid, power curve and tonal change detection. There is also a comprehensive SDK for use by developers of Vamp plugins and hosts. Sonic Visualiser is Free Software distributed under the GNU General Public License. The 0.9 release is available now in source code form or as binaries for Linux, OS/X, and Windows. For more information and downloads, please see http://www.sonicvisualiser.org/ For more information about Vamp plugins, please see http://www.sonicvisualiser.org/vamp.html See also the SourceForge page for this project at http://www.sourceforge.net/projects/sv1/ Sonic Visualiser was developed at the Centre for Digital Music, Queen Mary, University of London and partially funded by the European Commission through the SIMAC project IST-FP6-507142. Chris From paul at linuxaudiosystems.com Fri May 19 10:35:03 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri May 19 10:35:10 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605191527.15092.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> Message-ID: <1148049303.32289.26.camel@localhost.localdomain> On Fri, 2006-05-19 at 15:27 +0100, Chris Cannam wrote: > Announcing Sonic Visualiser, an application for viewing and analysing > the contents of music audio files. > > http://www.sonicvisualiser.org/ massive props! err, does that make me sound a like 40-something father of 3 trying to be cool? excellent work! --p From mista.tapas at gmx.net Fri May 19 11:54:38 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Fri May 19 11:54:59 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605191527.15092.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> Message-ID: <20060519175438.1754ee92@mango.fruits> On Fri, 19 May 2006 15:27:15 +0100 Chris Cannam wrote: > > Announcing Sonic Visualiser, an application for viewing and analysing > the contents of music audio files. > > http://www.sonicvisualiser.org/ Way cool :) Flo -- Palimm Palimm! http://tapas.affenbande.org From t_w_ at freenet.de Fri May 19 12:45:10 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Fri May 19 12:45:17 2006 Subject: [linux-audio-dev] LV2 Logo again In-Reply-To: <2c746f620605190928j6a8ec28buf6afc9fbe372705d@mail.gmail.com> References: <20060519140601.GA7342@charly.SWORD> <2c746f620605190928j6a8ec28buf6afc9fbe372705d@mail.gmail.com> Message-ID: <20060519164508.GB7342@charly.SWORD> On Fri, May 19, 2006 at 11:28:31AM -0500, Eric Shattow wrote: (snip) Not I decided, but Steve. Given his effort he has all the right to do so as far as I'm concerned and I support this decision. Please keep this thread clean of debate about the name from now. Best the whole list, actualy ;) --- Thorsten Wilms From torbenh at gmx.de Fri May 19 13:36:56 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri May 19 13:39:41 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] more questions on FST In-Reply-To: <1147968117.17100.81.camel@localhost.localdomain> References: <200605171335.28231.aaron@akjmusic.com> <20060517194344.GA17048@mobilat> <1147903839.10153.14.camel@mindpipe> <200605181759.17535.cuse@users.sourceforge.net> <1147968117.17100.81.camel@localhost.localdomain> Message-ID: <20060519173627.GA8229@mobilat> On Thu, May 18, 2006 at 12:01:57PM -0400, Paul Davis wrote: > On Thu, 2006-05-18 at 17:59 +0200, Christian Schoenebeck wrote: > > Es geschah am Thursday, 18. May 2006 00:10 als Lee Revell schrieb: > > > Does FST definitely require NPTL? > > > > That's a big fat YES! > > put differently: WINE requires NPTL to function adequately with > multithreaded applications. the segfault is coming from pthread_self() (in a signal_handler context or something) which does not work in that case... man it was 2004 when i debugged this... so it need TLS (Thread local Storage) at least. I dont think there are many builds of NPTL without TLS. so this is tightly coupled. > > --p > > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From t_w_ at freenet.de Fri May 19 14:13:57 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Fri May 19 14:14:01 2006 Subject: [linux-audio-dev] LV2 Logo again In-Reply-To: <2c746f620605191057u7f332d24u518351562a5ca331@mail.gmail.com> References: <20060519140601.GA7342@charly.SWORD> <2c746f620605190928j6a8ec28buf6afc9fbe372705d@mail.gmail.com> <20060519164508.GB7342@charly.SWORD> <2c746f620605191057u7f332d24u518351562a5ca331@mail.gmail.com> Message-ID: <20060519181357.GC7342@charly.SWORD> On Fri, May 19, 2006 at 12:57:34PM -0500, Eric Shattow wrote: > > How about using roman numerals in the logo? L|vii| ;) Already through it. Doesn't look that great and Steve and me would rather like to avoid any possible LV 2 vs LV II confusion. Should there ever be a LV 10, it should be LVX, though, because that's so cool ;) --- Thorsten Wilms From gene.heskett at verizon.net Sat May 20 03:31:04 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 03:31:10 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446D4591.1030603@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> Message-ID: <446EC5B8.6000006@verizon.net> Gene Heskett wrote: > Lee Revell wrote: >> On Thu, 2006-05-18 at 22:19 -0500, Gene Heskett wrote: >>> Any hints that result in getting something like skype or ekiga >>> working will be applied with many profuse thanks offered. >>> >> >> What ALSA version (/proc/asound/version)? >> > root@diablo skype]# cat /proc/asound/version > Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 > 08:57:20 2006 UTC). > >> Which driver is being used? > From an lsmod: > snd_atiixp_modem 15433 1 > snd_seq_dummy 3781 0 > snd_atiixp 19157 2 > snd_ac97_codec 83937 2 snd_atiixp_modem,snd_atiixp > snd_ac97_bus 2497 1 snd_ac97_codec > snd_seq_oss 28993 0 > snd_seq_midi_event 7105 1 snd_seq_oss > snd_seq 47153 5 > snd_seq_dummy,snd_seq_oss,snd_seq_midi_event > snd_seq_device 8909 3 snd_seq_dummy,snd_seq_oss,snd_seq > snd_pcm_oss 45009 0 > snd_mixer_oss 16449 2 snd_pcm_oss > snd_pcm 76869 4 > snd_atiixp_modem,snd_atiixp,snd_ac97_codec,snd_pcm_oss > snd_timer 22597 2 snd_seq,snd_pcm > snd 50501 14 > snd_atiixp_modem,snd_atiixp,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer > > soundcore 9377 2 snd > snd_page_alloc 10441 3 snd_atiixp_modem,snd_atiixp,snd_pcm > > >> Any change if you run the apps with "aoss"? e.g. "aoss ./skype" >> >> Lee >> >> > aoss apparently not installed: > [root@diablo skype]# aoss ./skype > bash: aoss: command not found > > Note that skype is the only oss program, but that ekiga and audacity are > similarly plagued. > > I can find no 'aoss' containing file with yumex. > I should add another program which is crippled by this same problem Lee, is grip. It can rip a cd, but cannot play the cd even when not ripping it. And the ripped sound isn't up to the usual quality, often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. A far cry from grips usual crystal clear results. Ditto for any other player program I'd tried and kde has a plethora of them, none can play a cd through the speakers. Audacities playback vu meters stay pretty consistently above the -2 db mark when a gripped ogg file is loaded, and will mark the red overload at someplace above 0 db before the whole selection loaded has played more than 10% of the piece. Is this sounding like any problem you've encountered? And, what rpm contains this 'aoss' thing? -- Cheers, Gene From paul at linuxaudiosystems.com Sat May 20 07:40:17 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat May 20 07:40:28 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446EC5B8.6000006@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> Message-ID: <1148125217.32289.47.camel@localhost.localdomain> On Sat, 2006-05-20 at 02:31 -0500, Gene Heskett wrote: > I should add another program which is crippled by this same problem Lee, > is grip. It can rip a cd, but cannot play the cd even when not > ripping it. And the ripped sound isn't up to the usual quality, often > sounding as if the playback is of a file that over-drove the d/a in > playback, or the a/d in the recording, eg clipped. A far cry from > grips usual crystal clear results. i use grip and skype and they both work perfectly for me. i suspect that your problem may be driver related rather than app related. i do not use aoss - generally i have JACK running on my hdsp interface and leave the builtin ICH5 interface for "consumer" applications (like skype, web browser playback etc) --p From gene.heskett at verizon.net Sat May 20 10:27:56 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 10:28:02 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <1148125217.32289.47.camel@localhost.localdomain> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> Message-ID: <446F276C.8060604@verizon.net> Paul Davis wrote: > On Sat, 2006-05-20 at 02:31 -0500, Gene Heskett wrote: >> I should add another program which is crippled by this same problem Lee, >> is grip. It can rip a cd, but cannot play the cd even when not >> ripping it. And the ripped sound isn't up to the usual quality, often >> sounding as if the playback is of a file that over-drove the d/a in >> playback, or the a/d in the recording, eg clipped. A far cry from >> grips usual crystal clear results. > > i use grip and skype and they both work perfectly for me. i suspect that > your problem may be driver related rather than app related. i do not use > aoss - generally i have JACK running on my hdsp interface and leave the > builtin ICH5 interface for "consumer" applications (like skype, web > browser playback etc) > > --p > hdsp? Thats a new one on me. This is an HP Pavilion dv5329us, and has the ATI-IXP audio stuffs loaded. There is an HDSPconf in the kde mutlimedia menu's, but it doesn't run when its launched. Is it supposed to, or does it need something running as a pre-requisite? -- Cheers, Gene From gene.heskett at verizon.net Sat May 20 11:22:45 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 11:22:50 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446F276C.8060604@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> Message-ID: <446F3445.7040109@verizon.net> Gene Heskett wrote: > Paul Davis wrote: >> On Sat, 2006-05-20 at 02:31 -0500, Gene Heskett wrote: >>> I should add another program which is crippled by this same problem >>> Lee, is grip. It can rip a cd, but cannot play the cd even when >>> not ripping it. And the ripped sound isn't up to the usual quality, >>> often sounding as if the playback is of a file that over-drove the >>> d/a in playback, or the a/d in the recording, eg clipped. A far cry >>> from grips usual crystal clear results. >> >> i use grip and skype and they both work perfectly for me. i suspect that >> your problem may be driver related rather than app related. i do not use >> aoss - generally i have JACK running on my hdsp interface and leave the >> builtin ICH5 interface for "consumer" applications (like skype, web >> browser playback etc) >> >> --p >> > hdsp? Thats a new one on me. This is an HP Pavilion dv5329us, and has > the ATI-IXP audio stuffs loaded. There is an HDSPconf in the kde > mutlimedia menu's, but it doesn't run when its launched. Is it supposed > to, or does it need something running as a pre-requisite? > I found that both HDSPMixer and HDSPConf were part of a previous 1.0.10 release of alsa-tools, and that this alsa-tools could be removed without any dependencies on the rest of the alsa install. However, there is not a replacement of this package for 1.0.11rcX. Was this something thats supposed to address this chipsets apparent inability to do full duplex audio? -- Cheers, Gene From paul at linuxaudiosystems.com Sat May 20 11:23:39 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat May 20 11:23:51 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446F276C.8060604@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> Message-ID: <1148138619.32289.52.camel@localhost.localdomain> On Sat, 2006-05-20 at 09:27 -0500, Gene Heskett wrote: > Paul Davis wrote: > > On Sat, 2006-05-20 at 02:31 -0500, Gene Heskett wrote: > >> I should add another program which is crippled by this same problem Lee, > >> is grip. It can rip a cd, but cannot play the cd even when not > >> ripping it. And the ripped sound isn't up to the usual quality, often > >> sounding as if the playback is of a file that over-drove the d/a in > >> playback, or the a/d in the recording, eg clipped. A far cry from > >> grips usual crystal clear results. > > > > i use grip and skype and they both work perfectly for me. i suspect that > > your problem may be driver related rather than app related. i do not use > > aoss - generally i have JACK running on my hdsp interface and leave the > > builtin ICH5 interface for "consumer" applications (like skype, web > > browser playback etc) > > > > --p > > > hdsp? Thats a new one on me. This is an HP Pavilion dv5329us, and has > the ATI-IXP audio stuffs loaded. There is an HDSPconf in the kde > mutlimedia menu's, but it doesn't run when its launched. Is it supposed > to, or does it need something running as a pre-requisite? an RME HDSP is a high end 26 channel digital audio interface. if you didn't spend US$600-1000 on it, you don't have it :) my point was that these apps work just fine using the builtin audio interface on my system(s). i think you have driver problems. --p From gene.heskett at verizon.net Sat May 20 12:07:12 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 12:07:19 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <1148138619.32289.52.camel@localhost.localdomain> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <1148138619.32289.52.camel@localhost.localdomain> Message-ID: <446F3EB0.3030606@verizon.net> Paul Davis wrote: > On Sat, 2006-05-20 at 09:27 -0500, Gene Heskett wrote: >> Paul Davis wrote: >>> On Sat, 2006-05-20 at 02:31 -0500, Gene Heskett wrote: >>>> I should add another program which is crippled by this same problem Lee, >>>> is grip. It can rip a cd, but cannot play the cd even when not >>>> ripping it. And the ripped sound isn't up to the usual quality, often >>>> sounding as if the playback is of a file that over-drove the d/a in >>>> playback, or the a/d in the recording, eg clipped. A far cry from >>>> grips usual crystal clear results. >>> i use grip and skype and they both work perfectly for me. i suspect that >>> your problem may be driver related rather than app related. i do not use >>> aoss - generally i have JACK running on my hdsp interface and leave the >>> builtin ICH5 interface for "consumer" applications (like skype, web >>> browser playback etc) >>> >>> --p >>> >> hdsp? Thats a new one on me. This is an HP Pavilion dv5329us, and has >> the ATI-IXP audio stuffs loaded. There is an HDSPconf in the kde >> mutlimedia menu's, but it doesn't run when its launched. Is it supposed >> to, or does it need something running as a pre-requisite? > > an RME HDSP is a high end 26 channel digital audio interface. if you > didn't spend US$600-1000 on it, you don't have it :) > > my point was that these apps work just fine using the builtin audio > interface on my system(s). i think you have driver problems. > > --p > Or chipset problems. Occasionally, skype will run for a few minutes before things start pulling the flush handle, almost as if its heat related. Having the hammer of being a CET, one tends to think of hardware as the nail. Are there newer alsa things to try? This is a fully uptodate FC5 install, i386 on an amd turion 64. > > -- Cheers, Gene From _ at whats-your.name Sat May 20 13:07:29 2006 From: _ at whats-your.name (c) Date: Sat May 20 13:07:28 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <446F276C.8060604@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> Message-ID: <20060520170729.GA21295@replic.net> On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: > often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. ... > the ATI-IXP audio stuffs loaded the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. From rlrevell at joe-job.com Sat May 20 13:09:38 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 20 13:09:50 2006 Subject: [linux-audio-dev] Skype, ekiga, audacity, other audio util probs. In-Reply-To: <446F3EB0.3030606@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <1148138619.32289.52.camel@localhost.localdomain> <446F3EB0.3030606@verizon.net> Message-ID: <1148144979.20472.16.camel@mindpipe> On Sat, 2006-05-20 at 11:07 -0500, Gene Heskett wrote: > Or chipset problems. Occasionally, skype will run for a few minutes > before things start pulling the flush handle, almost as if its heat > related. Having the hammer of being a CET, one tends to think of > hardware as the nail. > > Are there newer alsa things to try? This is a fully uptodate FC5 > install, i386 on an amd turion 64. You could try ALSA 1.0.11, but I don't think this driver has changed. I would report the bug to the alsa-user list. Lee From rlrevell at joe-job.com Sat May 20 13:10:33 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 20 13:10:39 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <20060520170729.GA21295@replic.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> Message-ID: <1148145034.20472.18.camel@mindpipe> On Sat, 2006-05-20 at 17:07 +0000, c wrote: > On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: > > often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. > ... > > the ATI-IXP audio stuffs loaded > > the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. > Distortion if all volumes are set to 100% is not necessarily a bug. It's just the way some hardware works. Lee From _ at whats-your.name Sat May 20 13:10:55 2006 From: _ at whats-your.name (c) Date: Sat May 20 13:11:11 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <20060520170729.GA21295@replic.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> Message-ID: <20060520171055.GB21295@replic.net> > the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits im leaning towards the former, since it sounds like an analog distortion, more than digital clipping. but ive never written a Driver or examined the schematics for commodity AC'97 implementations... not sure how to cap the volume at 80% with aoss, though. wasnt around in the OSS days..and prefer my apps don't relive them ;) From rlrevell at joe-job.com Sat May 20 13:52:30 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat May 20 13:52:38 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <20060520171055.GB21295@replic.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> <20060520171055.GB21295@replic.net> Message-ID: <1148147551.20472.21.camel@mindpipe> On Sat, 2006-05-20 at 17:10 +0000, c wrote: > not sure how to cap the volume at 80% with aoss, though. wasnt around in the OSS days..and prefer my apps don't relive them ;) > Just don't turn up the PCM control past 80%. Lee From gene.heskett at verizon.net Sat May 20 17:53:08 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 17:53:16 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <20060520170729.GA21295@replic.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> Message-ID: <446F8FC4.8070101@verizon.net> c wrote: > On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: >> often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. > ... >> the ATI-IXP audio stuffs loaded > > the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. > Uh huh, and when running skype. ekiga, audacity, or anything else that requires this full duplex operation, it doesn't effect this particular phenom other than turning the overall volume down, and when you run it back up to the audible level, its still doing it with as much enthusiasm as when you turned it down for effects. It specifically is not related to any gain control's settings. -- Cheers, Gene From gene.heskett at verizon.net Sat May 20 17:55:09 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat May 20 17:55:14 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <1148145034.20472.18.camel@mindpipe> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> <1148145034.20472.18.camel@mindpipe> Message-ID: <446F903D.7070201@verizon.net> Lee Revell wrote: > On Sat, 2006-05-20 at 17:07 +0000, c wrote: >> On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: >>> often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. >> ... >>> the ATI-IXP audio stuffs loaded >> the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. >> > > Distortion if all volumes are set to 100% is not necessarily a bug. > It's just the way some hardware works. > > Lee > > We understand that all too well, from doing that particular balanceing act with the older SBLive cards, which could be run plumb out of digital headroom without even trying. -- Cheers, Gene From James at superbug.co.uk Sun May 21 04:15:31 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun May 21 04:15:39 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <20060520170729.GA21295@replic.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> Message-ID: <447021A3.10600@superbug.co.uk> c wrote: > On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: >> often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. > ... >> the ATI-IXP audio stuffs loaded > > the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. If you are using alsamixer to set gain levels, that currently it is kind of hit and miss as to what 100% actually means. On some cards 100% is 0dB gain, on others it can be +12dB gain. So, setting your control to 100% might be causing a +12dB gain to the signal, that of course would over drive it and cause clipping. I will be implementing at some point, support for displaying dB gain values in alsamixer, so the problem you are having will disappear, because you will be able to then tell exactly what position to put the gain slider to get 0dB gain. James From gene.heskett at verizon.net Sun May 21 08:24:18 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun May 21 08:24:26 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <447021A3.10600@superbug.co.uk> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> <447021A3.10600@superbug.co.uk> Message-ID: <44705BF2.3020500@verizon.net> James Courtier-Dutton wrote: > c wrote: >> On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: >>> often sounding as if the playback is of a file that over-drove the d/a in playback, or the a/d in the recording, eg clipped. >> ... >>> the ATI-IXP audio stuffs loaded >> the ATIIXP in my MSI exhibits this same issue. essentially, if the 'PCM' level is set to 100%, things are horribly overdriven. the solution is to set the Master to 100%, and adjust volume with PCM, instead of vice versa. i guess whether this is a hardware bug or a driver bug depends on if PCM is the last point of software contact with the stream and master trims the levels after that, or if PCM just does some multiplication on the bits before passing them to the Master.. > > If you are using alsamixer to set gain levels, that currently it is kind > of hit and miss as to what 100% actually means. > On some cards 100% is 0dB gain, on others it can be +12dB gain. > So, setting your control to 100% might be causing a +12dB gain to the > signal, that of course would over drive it and cause clipping. > > I will be implementing at some point, support for displaying dB gain > values in alsamixer, so the problem you are having will disappear, > because you will be able to then tell exactly what position to put the > gain slider to get 0dB gain. > > James That would be hardware dependent of course, but first, I need to make the hardware work. How am I to know when grip is running and ripping a cd that I can't hear the contents of till its been ripped, if the gain control labeled 'cd' actually works? To me, its an extra eye candy only control in kmix's window. > > -- Cheers, Gene From gene.heskett at verizon.net Sun May 21 08:45:24 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun May 21 08:45:31 2006 Subject: [linux-audio-dev] ATI-IXP overdrives PCM In-Reply-To: <44705BF2.3020500@verizon.net> References: <446D395E.6030002@verizon.net> <1148009506.32630.57.camel@mindpipe> <446D4591.1030603@verizon.net> <446EC5B8.6000006@verizon.net> <1148125217.32289.47.camel@localhost.localdomain> <446F276C.8060604@verizon.net> <20060520170729.GA21295@replic.net> <447021A3.10600@superbug.co.uk> <44705BF2.3020500@verizon.net> Message-ID: <447060E4.4020907@verizon.net> Gene Heskett wrote: > James Courtier-Dutton wrote: >> c wrote: >>> On Sat May 20, 2006 at 09:27:56AM -0500, Gene Heskett wrote: >>>> often sounding as if the playback is of a file that over-drove the >>>> d/a in playback, or the a/d in the recording, eg clipped. >>> ... >>>> the ATI-IXP audio stuffs loaded >>> the ATIIXP in my MSI exhibits this same issue. essentially, if the >>> 'PCM' level is set to 100%, things are horribly overdriven. the >>> solution is to set the Master to 100%, and adjust volume with PCM, >>> instead of vice versa. i guess whether this is a hardware bug or a >>> driver bug depends on if PCM is the last point of software contact >>> with the stream and master trims the levels after that, or if PCM >>> just does some multiplication on the bits before passing them to the >>> Master.. >> >> If you are using alsamixer to set gain levels, that currently it is kind >> of hit and miss as to what 100% actually means. >> On some cards 100% is 0dB gain, on others it can be +12dB gain. >> So, setting your control to 100% might be causing a +12dB gain to the >> signal, that of course would over drive it and cause clipping. >> >> I will be implementing at some point, support for displaying dB gain >> values in alsamixer, so the problem you are having will disappear, >> because you will be able to then tell exactly what position to put the >> gain slider to get 0dB gain. >> >> James > > That would be hardware dependent of course, but first, I need to make > the hardware work. How am I to know when grip is running and ripping a > cd that I can't hear the contents of till its been ripped, if the gain > control labeled 'cd' actually works? To me, its an extra eye candy only > control in kmix's window. >> ADDENDUM: I just now located some mandrake i586 versions of those two files that give aoss, in 1.0.11 versions and installed them (no dependencies!), but either my .asoundrc is fubar, or it doesn't work as suggested. skype then gives a reported problem with the sound device (and has no paths open to either /dev/dsp or to /dev/mixer) when launched with 'aoss skype'. Removing he aoss from the command line puts it back at condition one, where the test call disappears into the stuttering, with the small snippet echo being repeated at about 1.5 second intervals till the skype service terminates the call. My current .asoundrc: Critique please... root@diablo ~]# cat .asoundrc pcm.atiixp { type hw card 0 } ctl.atiixp { type hw card 0 } pcm.!default { type hw card 0 } ctl.!default { type hw card 0 } -- Cheers, Gene From doj at cubic.org Mon May 22 05:32:21 2006 From: doj at cubic.org (Dirk Jagdmann) Date: Mon May 22 05:32:24 2006 Subject: [linux-audio-dev] LV2 Logo again In-Reply-To: <20060519140601.GA7342@charly.SWORD> References: <20060519140601.GA7342@charly.SWORD> Message-ID: <44718525.8050405@cubic.org> > More work on the logo: > http://affenbande.org/~thorwil/wordpress/2006/05/19/lv2-5/ I like B3 and F3. -- ---> Dirk Jagdmann ^ doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org From piem at altern.org Mon May 22 08:59:44 2006 From: piem at altern.org (Paul Brossier) Date: Mon May 22 09:00:16 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 Message-ID: <20060522125944.GA7066@pomme.anchorland.local> The latest version of aubio, 0.3.0, is now available. aubio is a library for audio labelling. The goal of this project is to provide automatic feature extraction algorithms to other audio software projects. Features include onset detection, beat tracking, and pitch detection. Functions can be used offline in sound editors and software samplers, or online in audio effects and virtual instruments. This release features several changes: * new pitch detection method, yinfft * new beat tracking algorithm (improved from 0.2.0) * new puredata external * enhancements to the onset detection algorithms * improved aubiocut, can now slice at beats and silences * new aubiopitch python program to extract pitch tracks * plotting features for aubiocut and aubiopitch * python interface refactored * updated documentation As usual, the source code can be found at http://aubio.piem.org/ , and Debian packages are available from http://piem.org/debian/ . Feedback most appreciated! Paul Brossier From yomguy at altern.org Mon May 22 09:20:53 2006 From: yomguy at altern.org (Guillaume Pellerin) Date: Mon May 22 09:21:48 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060522125944.GA7066@pomme.anchorland.local> References: <20060522125944.GA7066@pomme.anchorland.local> Message-ID: <4471BAB5.2040508@altern.org> So goood ;) Paul Brossier wrote: > The latest version of aubio, 0.3.0, is now available. aubio is a library > for audio labelling. The goal of this project is to provide automatic > feature extraction algorithms to other audio software projects. Features > include onset detection, beat tracking, and pitch detection. Functions > can be used offline in sound editors and software samplers, or online in > audio effects and virtual instruments. > > This release features several changes: > > * new pitch detection method, yinfft > * new beat tracking algorithm (improved from 0.2.0) > * new puredata external > * enhancements to the onset detection algorithms > * improved aubiocut, can now slice at beats and silences > * new aubiopitch python program to extract pitch tracks > * plotting features for aubiocut and aubiopitch > * python interface refactored > * updated documentation > > As usual, the source code can be found at http://aubio.piem.org/ , > and Debian packages are available from http://piem.org/debian/ . > > Feedback most appreciated! > > Paul Brossier > -- http://yomix.org From fbar at footils.org Mon May 22 09:34:27 2006 From: fbar at footils.org (Frank Barknecht) Date: Mon May 22 09:34:42 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060522125944.GA7066@pomme.anchorland.local> References: <20060522125944.GA7066@pomme.anchorland.local> Message-ID: <20060522133426.GS5869@fliwatut.scifi> Hallo, Paul Brossier hat gesagt: // Paul Brossier wrote: > The latest version of aubio, 0.3.0, is now available. aubio is a library > for audio labelling. The goal of this project is to provide automatic > feature extraction algorithms to other audio software projects. Features > include onset detection, beat tracking, and pitch detection. Functions > can be used offline in sound editors and software samplers, or online in > audio effects and virtual instruments. > > This release features several changes: > > * new pitch detection method, yinfft > * new beat tracking algorithm (improved from 0.2.0) > * new puredata external Hoohoo, wonderful, works great with Pd! Minor nitpick: Generally help-patches in Pd nowadays follow the naming convention: "NAME-help.pd" instead of "help-NAME.pd" as in the aubio-distribution. Maybe you can change this in future versions. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From pshirkey at boosthardware.com Mon May 22 18:11:33 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon May 22 18:12:15 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060522125944.GA7066@pomme.anchorland.local> References: <20060522125944.GA7066@pomme.anchorland.local> Message-ID: <44723715.4070906@boosthardware.com> Paul Brossier wrote: > The latest version of aubio, 0.3.0, is now available. aubio is a library > for audio labelling. The goal of this project is to provide automatic > feature extraction algorithms to other audio software projects. Features > include onset detection, beat tracking, and pitch detection. Functions > can be used offline in sound editors and software samplers, or online in > audio effects and virtual instruments. > > This release features several changes: > > * new pitch detection method, yinfft > * new beat tracking algorithm (improved from 0.2.0) > * new puredata external > * enhancements to the onset detection algorithms > * improved aubiocut, can now slice at beats and silences > * new aubiopitch python program to extract pitch tracks > * plotting features for aubiocut and aubiopitch > * python interface refactored > * updated documentation > > As usual, the source code can be found at http://aubio.piem.org/ , > and Debian packages are available from http://piem.org/debian/ . > > Feedback most appreciated! > > Paul Brossier > Hi Paul, This looks like it could be a useful addition to jackEQ. Do you mind having a look http://jackeq.sf.net and letting me know how you think it could be applied? Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From jack.oquin at gmail.com Mon May 22 20:12:22 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Mon May 22 20:12:46 2006 Subject: [linux-audio-dev] [ANN] realtime-lsm 0.8.6 available via SourceForge Message-ID: Download links (once SF finishes updating mirrors)... http://prdownloads.sourceforge.net/realtime-lsm/rt-lsm-0.8.6-kernel.patch.gz?download http://prdownloads.sourceforge.net/realtime-lsm/realtime-lsm-0.8.6.tar.gz?download The Realtime Linux Security Module (LSM) is a loadable extension for Linux 2.6 kernels. It selectively grants realtime permissions to specific user groups or applications. This release provides the kernel patch formerly included in Andrew Morton's kernel development tree. This module is no longer available there, so I am releasing it for download via SourceForge. The kernel developers prefer their own rlimits solution for granting realtime privileges. Since that is their responsibility, I defer to their feelings. Since their solution requires PAM updates which have been very slow to appear in end-user distributions, I continue to provide this (simpler) solution via SourceForge for those who need it. There are no new features. You need not update, if an older version still works for you. This patch is not actively being developed, but I will continue to provide support as needed for the many users of distributions still lacking the required PAM updates for the rlimits solution preferred by the kernel developers. This release only supports kernel version 2.6.6 and newer. For older kernels, realtime-lsm-0.1.1 is still available. This LSM was written by Torben Hohn and Jack O'Quin, who make no warranty concerning the safety, security or even stability of your system when using it. But, if you do have problems, please report them on the linux-audio-user@music.columbia.edu mailing list -- joq From asbjs at stud.ntnu.no Tue May 23 05:45:27 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Tue May 23 05:45:12 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605191527.15092.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> Message-ID: <20060523094527.GA31085@stud.ntnu.no> On Fri, May 19, 2006 at 03:27:15PM +0100, Chris Cannam wrote: > > Announcing Sonic Visualiser, an application for viewing and analysing > the contents of music audio files. > > http://www.sonicvisualiser.org/ > [...] Thanks! I haven't looked much into it yet, but this seems like a great tool. I do however have problems with audio playback, with Sonic Visualiser (SV) reporting that it is not able to open an audio device. What I do: ---------- * I start qjackctl, and start jack, with no appearant errors. * I start SV, open a new session, and import an audio file. (So far, I have tried mp3 and wav.) The file is displayed, and an notification box pops up, with the text "Could not open an audio device for playback. Audio playback will not be available during this session." The output from SV (all of it included further below) says that -------------- ERROR: AudioJACKTarget: Failed to connect to JACK server WARNING: AudioTargetFactory::createCallbackTarget: Failed to open JACK target -------------- There is no sign of anything related to SV in the qjackctl "Connections" window nor in the "Messages" window. What I'd expect: ---------------- I would have expected SV to connect to the running jack without any problems. Especially since other programs (timemachine, hydrogen) seems to connect without any problems. (I am able to play back with hydrogen.) Questions: ---------- Why doesn't SV connect to jack? Am I doing anything wrong? What should I try next? With kind regards, Asbj?rn S?b? The full output from SV (started from a terminal): -------------------------------------------------- asbjs@ansatt20:~/tmp$ ./sonic-visualiser GetProcessStatus returned correct status for this process FeatureExtractionPluginFactory::instance(vamp): creating new FeatureExtractionPluginFactory VAMP path is: "/usr/local/lib/vamp:/usr/lib/vamp:/home/asbjs/vamp:/home/asbjs/.vamp" [/home/asbjs/dssi] [/home/asbjs/.dssi] [/usr/local/lib/dssi] [/usr/lib/dssi] [/home/asbjs/.ladspa] [/usr/local/lib/ladspa] [/usr/lib/ladspa] QPainter::begin: Widget painting can only begin as a result of a paintEvent Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first QPainter::begin: Widget painting can only begin as a result of a paintEvent Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first ERROR: AudioJACKTarget: Failed to connect to JACK server WARNING: AudioTargetFactory::createCallbackTarget: Failed to open JACK target ERROR: AudioPortAudioTarget: Failed to initialize PortAudio WARNING: AudioTargetFactory::createCallbackTarget: Failed to open PortAudio target WARNING: AudioTargetFactory::createCallbackTarget: No suitable targets available From cannam at all-day-breakfast.com Tue May 23 05:58:00 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Tue May 23 05:58:18 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <20060523094527.GA31085@stud.ntnu.no> References: <200605191527.15092.cannam@all-day-breakfast.com> <20060523094527.GA31085@stud.ntnu.no> Message-ID: <200605231058.01059.cannam@all-day-breakfast.com> On Tuesday 23 May 2006 10:45, Asbj?rn S?b? wrote: > ERROR: AudioJACKTarget: Failed to connect to JACK server Are you running the static build from the download page, or did you build SV yourself? The static build has libjack 0.100 statically linked. If your version of jackd is incompatible with the linked version, it will fall back to ALSA via PortAudio (which presumably fails because JACK is using the soundcard). So, if you're using this build, which version of jackd do you have? Chris From sk at k-hornz.de Tue May 23 06:11:11 2006 From: sk at k-hornz.de (stefan kersten) Date: Tue May 23 06:11:55 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605191527.15092.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> Message-ID: <1148379071.3707.7.camel@localhost> On Fr, 2006-05-19 at 15:27 +0100, Chris Cannam wrote: > Announcing Sonic Visualiser, an application for viewing and analysing > the contents of music audio files. > > http://www.sonicvisualiser.org/ this application is really great! exactly what we needed for our current project ... just one gripe: the queen mary plugins are only available as binaries for i686. would it be possible to provide a ppc-linux version? From pieterp at joow.be Tue May 23 06:16:21 2006 From: pieterp at joow.be (Pieter Palmers) Date: Tue May 23 06:16:33 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <44723715.4070906@boosthardware.com> References: <20060522125944.GA7066@pomme.anchorland.local> <44723715.4070906@boosthardware.com> Message-ID: <4472E0F5.2060907@joow.be> Patrick Shirkey wrote: > Paul Brossier wrote: > >> The latest version of aubio, 0.3.0, is now available. aubio is a library >> for audio labelling. The goal of this project is to provide automatic >> feature extraction algorithms to other audio software projects. Features >> include onset detection, beat tracking, and pitch detection. Functions >> can be used offline in sound editors and software samplers, or online in >> audio effects and virtual instruments. >> >> This release features several changes: >> >> * new pitch detection method, yinfft >> * new beat tracking algorithm (improved from 0.2.0) >> * new puredata external * enhancements to the onset detection >> algorithms >> * improved aubiocut, can now slice at beats and silences >> * new aubiopitch python program to extract pitch tracks >> * plotting features for aubiocut and aubiopitch >> * python interface refactored >> * updated documentation >> As usual, the source code can be found at http://aubio.piem.org/ >> , and Debian packages are available from http://piem.org/debian/ . >> Feedback most appreciated! >> >> Paul Brossier >> > > Hi Paul, > > This looks like it could be a useful addition to jackEQ. > > Do you mind having a look http://jackeq.sf.net and letting me know how > you think it could be applied? I had this idea once to use aubio to implement a 'jackd transport time sync source', i.e. retrieving the bpm and adjusting the beat so that jackd-transport aware applications (like hydrogen) can run in sync with external music. The idea is to enable easy live use of drum machines, samplers and tempo aware audio players in e.g. a DJ context. But this could also be used to automatically create the Tap tempo for delays etc... I even started to implement this, but some other coding got in the way... Greets, Pieter From asbjs at stud.ntnu.no Tue May 23 06:18:02 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Tue May 23 06:18:08 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605231058.01059.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> <20060523094527.GA31085@stud.ntnu.no> <200605231058.01059.cannam@all-day-breakfast.com> Message-ID: <20060523101802.GA2779@stud.ntnu.no> On Tue, May 23, 2006 at 10:58:00AM +0100, Chris Cannam wrote: > On Tuesday 23 May 2006 10:45, Asbj?rn S?b? wrote: > > ERROR: AudioJACKTarget: Failed to connect to JACK server > > Are you running the static build from the download page, or did you > build SV yourself? The static build from the download page > The static build has libjack 0.100 statically linked. If your version > of jackd is incompatible with the linked version, it will fall back to > ALSA via PortAudio (which presumably fails because JACK is using the > soundcard). So, if you're using this build, which version of jackd do > you have? jackd 0.99.54 Does this explain it? However, if I stop jack, I still get the same behaviour (and the same error messages) from SV. Even though I can play back the very same file all right using aplay. (See below. The playback with aplay is interrupted by me.) With kind regards, Asbj?rn asbjs@ansatt20:~/tmp$ aplay /local/musikkfiler/wav/ole_edvard_antonsen/tour_de_force/Track01.wav Playing WAVE '/local/musikkfiler/wav/ole_edvard_antonsen/tour_de_force/Track01.wav' : Signed 16 bit Little Endian,Rate 44100 Hz, Stereo Aborted by signal Interrupt... asbjs@ansatt20:~/tmp$ ./sonic-visualiser /local/musikkfiler/wav/ole_edvard_antonsen/tour_de_force/Track01.wav GetProcessStatus returned correct status for this process FeatureExtractionPluginFactory::instance(vamp): creating new FeatureExtractionPluginFactory VAMP path is: "/usr/local/lib/vamp:/usr/lib/vamp:/home/asbjs/vamp:/home/asbjs/.vamp" [/home/asbjs/dssi] [/home/asbjs/.dssi] [/usr/local/lib/dssi] [/usr/lib/dssi] [/home/asbjs/.ladspa] [/usr/local/lib/ladspa] [/usr/lib/ladspa] QPainter::begin: Widget painting can only begin as a result of a paintEvent Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first Document::addLayerToView: Layer with no model being added to view: normally you want to set the model first ERROR: AudioJACKTarget: Failed to connect to JACK server WARNING: AudioTargetFactory::createCallbackTarget: Failed to open JACK target ERROR: AudioPortAudioTarget: Failed to initialize PortAudio WARNING: AudioTargetFactory::createCallbackTarget: Failed to open PortAudio target WARNING: AudioTargetFactory::createCallbackTarget: No suitable targets available application.exec() returned 0 From asbjs at stud.ntnu.no Tue May 23 06:20:21 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Tue May 23 06:20:08 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <20060523101802.GA2779@stud.ntnu.no> References: <200605191527.15092.cannam@all-day-breakfast.com> <20060523094527.GA31085@stud.ntnu.no> <200605231058.01059.cannam@all-day-breakfast.com> <20060523101802.GA2779@stud.ntnu.no> Message-ID: <20060523102021.GB2779@stud.ntnu.no> On Tue, May 23, 2006 at 12:18:02PM +0200, Asbj?rn S?b? wrote: > [...] > However, if I stop jack, I still get the same behaviour (and the same > error messages) from SV. Even though I can play back the very same > file all right using aplay. But of course, I probably do not have port-audio installed. (Sorry, did not think about that one.) Asbj?rn From letz at grame.fr Tue May 23 06:49:19 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Tue May 23 06:51:14 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605231058.01059.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> <20060523094527.GA31085@stud.ntnu.no> <200605231058.01059.cannam@all-day-breakfast.com> Message-ID: <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> Le 23 mai 06 ? 11:58, Chris Cannam a ?crit : > On Tuesday 23 May 2006 10:45, Asbj?rn S?b? wrote: >> ERROR: AudioJACKTarget: Failed to connect to JACK server > > Are you running the static build from the download page, or did you > build SV yourself? > > The static build has libjack 0.100 statically linked. If your version > of jackd is incompatible with the linked version, it will fall back to > ALSA via PortAudio (which presumably fails because JACK is using the > soundcard). So, if you're using this build, which version of jackd do > you have? > > > Chris Why do you do a static with libjack? I was thinking jack was supposed to always be used with a shared lib version... Stephane Letz From cannam at all-day-breakfast.com Tue May 23 07:11:23 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Tue May 23 07:11:25 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> Message-ID: <200605231211.23490.cannam@all-day-breakfast.com> On Tuesday 23 May 2006 11:49, St?phane Letz wrote: > Why do you do a static with libjack? I was thinking jack was > supposed to always be used with a shared lib version... Well, what is the proper solution when distributing a binary? 1. Link libjack statically 2. Omit JACK support Just linking dynamically isn't an option. I want to fall back on another output if JACK is absent, not fail to start at all. I suppose there may be 3. dlopen libjack from within the program and continue if it fails I haven't tried that; is it a reasonable option? Chris From cannam at all-day-breakfast.com Tue May 23 07:18:49 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Tue May 23 07:18:57 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <20060523102021.GB2779@stud.ntnu.no> References: <200605191527.15092.cannam@all-day-breakfast.com> <20060523101802.GA2779@stud.ntnu.no> <20060523102021.GB2779@stud.ntnu.no> Message-ID: <200605231218.49948.cannam@all-day-breakfast.com> On Tuesday 23 May 2006 11:20, Asbj?rn S?b? wrote: > But of course, I probably do not have port-audio installed. That shouldn't matter -- it's linked statically... Chris From contact at alexandredenis.net Tue May 23 07:54:56 2006 From: contact at alexandredenis.net (Alexandre DENIS) Date: Tue May 23 07:55:11 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605231211.23490.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> <200605231211.23490.cannam@all-day-breakfast.com> Message-ID: <4472F810.90503@alexandredenis.net> Chris Cannam wrote: > On Tuesday 23 May 2006 11:49, St?phane Letz wrote: >> Why do you do a static with libjack? I was thinking jack was >> supposed to always be used with a shared lib version... > > Well, what is the proper solution when distributing a binary? > > 1. Link libjack statically > 2. Omit JACK support > > Just linking dynamically isn't an option. I want to fall back on > another output if JACK is absent, not fail to start at all. > > I suppose there may be > > 3. dlopen libjack from within the program and continue if it fails > > I haven't tried that; is it a reasonable option? It would require to dlsym() every libjack symbol. A better option seems to be: 4. dlopen() your jack backend, itself beeing dynamically linked against libjack. -a. From letz at grame.fr Tue May 23 08:43:03 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Tue May 23 08:45:00 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <200605231211.23490.cannam@all-day-breakfast.com> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> <200605231211.23490.cannam@all-day-breakfast.com> Message-ID: Le 23 mai 06 ? 13:11, Chris Cannam a ?crit : > On Tuesday 23 May 2006 11:49, St?phane Letz wrote: >> Why do you do a static with libjack? I was thinking jack was >> supposed to always be used with a shared lib version... > > Well, what is the proper solution when distributing a binary? > > 1. Link libjack statically > 2. Omit JACK support > > Just linking dynamically isn't an option. I want to fall back on > another output if JACK is absent, not fail to start at all. > > I suppose there may be > > 3. dlopen libjack from within the program and continue if it fails > > I haven't tried that; is it a reasonable option? > > > Chris Is any kind of "weak linking" supported? Stephane From paul at linuxaudiosystems.com Tue May 23 08:59:33 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue May 23 08:59:53 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <4472F810.90503@alexandredenis.net> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> <200605231211.23490.cannam@all-day-breakfast.com> <4472F810.90503@alexandredenis.net> Message-ID: <1148389174.5302.9.camel@localhost.localdomain> On Tue, 2006-05-23 at 13:54 +0200, Alexandre DENIS wrote: > > 3. dlopen libjack from within the program and continue if it fails > > > > I haven't tried that; is it a reasonable option? > > It would require to dlsym() every libjack symbol. A better option seems > to be: i don't believe that is true. if you link with RTLD_GLOBAL, then dlopen () followed by dlsym jack_client_open() should be all that is needed. if what you are suggesting is true, run-time linking could never work. --p From contact at alexandredenis.net Tue May 23 10:17:17 2006 From: contact at alexandredenis.net (Alexandre DENIS) Date: Tue May 23 10:17:30 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <1148389174.5302.9.camel@localhost.localdomain> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> <200605231211.23490.cannam@all-day-breakfast.com> <4472F810.90503@alexandredenis.net> <1148389174.5302.9.camel@localhost.localdomain> Message-ID: <4473196D.7070808@alexandredenis.net> Paul Davis wrote: > > i don't believe that is true. if you link with RTLD_GLOBAL, then dlopen > () followed by dlsym jack_client_open() should be all that is needed. Additionnaly, you'll need to link the main binary with -Wl,--unresolved-symbols=ignore-all which is not the cleanest thing to do :-) Imho, a dlopen'ed driver for each backend is much better than playing with ignored undefined symbols. -a. From piem at altern.org Tue May 23 12:13:11 2006 From: piem at altern.org (Paul Brossier) Date: Tue May 23 12:13:28 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <4472E0F5.2060907@joow.be> References: <20060522125944.GA7066@pomme.anchorland.local> <44723715.4070906@boosthardware.com> <4472E0F5.2060907@joow.be> Message-ID: <20060523161311.GA12477@pomme.anchorland.local> Hi all, On Tue, May 23, 2006 at 12:16:21PM +0200, Pieter Palmers wrote: > Patrick Shirkey wrote: > > >Paul Brossier wrote: > > > >>The latest version of aubio, 0.3.0, is now available. aubio is a library > >>for audio labelling. The goal of this project is to provide automatic > >>feature extraction algorithms to other audio software projects. Features > >>include onset detection, beat tracking, and pitch detection. Functions > >>can be used offline in sound editors and software samplers, or online in > >>audio effects and virtual instruments. > >> > >>This release features several changes: > >> > >> * new pitch detection method, yinfft > >> * new beat tracking algorithm (improved from 0.2.0) > >> * new puredata external * enhancements to the onset detection > >>algorithms > >> * improved aubiocut, can now slice at beats and silences > >> * new aubiopitch python program to extract pitch tracks > >> * plotting features for aubiocut and aubiopitch > >> * python interface refactored > >> * updated documentation > >> As usual, the source code can be found at http://aubio.piem.org/ > >>, and Debian packages are available from http://piem.org/debian/ . > >>Feedback most appreciated! > >> > >>Paul Brossier > >> > > > >Hi Paul, > > > >This looks like it could be a useful addition to jackEQ. > > > >Do you mind having a look http://jackeq.sf.net and letting me know how > >you think it could be applied? Maybe you have an idea in mind? :-) I guess a tap flashing at beats and displaying the detected tempo would be interesting for jackeq. Other features (onset, pitch) could also be helpful, as monitoring tools, and even to `autodrive' plugins (limiter, eq). > I had this idea once to use aubio to implement a 'jackd transport time > sync source', i.e. retrieving the bpm and adjusting the beat so that > jackd-transport aware applications (like hydrogen) can run in sync with > external music. > > The idea is to enable easy live use of drum machines, samplers and tempo > aware audio players in e.g. a DJ context. But this could also be used to > automatically create the Tap tempo for delays etc... Yes, an automatic beat tapping tool, which could be manually corrected, just like a normal tap. > I even started to implement this, but some other coding got in the way... IIRC, support for Jack transport could be added using Timebase Master: http://jackit.sourceforge.net/docs/reference/html/transport-design.html#timebase Which program is using the Timebase? code examples would help here :-) Greetings, Paul From piem at altern.org Tue May 23 12:18:07 2006 From: piem at altern.org (Paul Brossier) Date: Tue May 23 12:18:34 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060522133426.GS5869@fliwatut.scifi> References: <20060522125944.GA7066@pomme.anchorland.local> <20060522133426.GS5869@fliwatut.scifi> Message-ID: <20060523161807.GB12477@pomme.anchorland.local> Hi, On Mon, May 22, 2006 at 03:34:27PM +0200, Frank Barknecht wrote: > Hallo, > Paul Brossier hat gesagt: // Paul Brossier wrote: > > > The latest version of aubio, 0.3.0, is now available. aubio is a library > > for audio labelling. The goal of this project is to provide automatic > > feature extraction algorithms to other audio software projects. Features > > include onset detection, beat tracking, and pitch detection. Functions > > can be used offline in sound editors and software samplers, or online in > > audio effects and virtual instruments. > > > > This release features several changes: > > > > * new pitch detection method, yinfft > > * new beat tracking algorithm (improved from 0.2.0) > > * new puredata external > > Hoohoo, wonderful, works great with Pd! Great to know it works there too :) > Minor nitpick: Generally help-patches in Pd nowadays follow the naming > convention: "NAME-help.pd" instead of "help-NAME.pd" as in the > aubio-distribution. Maybe you can change this in future versions. Ah, thanks for noticing! This will be fixed in the next release. I sent the announcement to pd-announce too, with this about the external: This release features several changes and includes a Puredata external, containing 5 objects: * aubiopitch~ pitch tracking object, similar to fiddle~ and pick~ * aubioonset~ onset detection, similar to bonk~ * aubiotempo~ beat tracking * aubiotss~ transient / steady state separation (experimental) * aubioquiet~ simple silence detector Not all aubio features are available from PD yet, but onset and pitch detection routines should be more robust than other existing externals. Bye, Paul From dlphillips at woh.rr.com Tue May 23 17:01:14 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue May 23 16:55:36 2006 Subject: [linux-audio-dev] logos wanted Message-ID: <4473781A.5090708@woh.rr.com> Greetings: I'm spiffing up the Linux soundapps site, adding logos to the front page. I'm missing logos for Ardour and Rosegarden, are they around anywhere ? I'll try to update the site tonight, I'll be happy to add any new logos as I receive them. Please send them to me off-list, thanks. I have these already: linuxaudio.org LAD LAU Demudi dynebolic Planet CCRMA APODIO Studio To Go Musix 64Studio JackLab LAM ALSA JACK LADSPA FST Audacity ReZound ecasound Sweep Hydrogen CLAM Csound RTCmix LinuxSampler MusE seq24 BEAST xiph.org GRip Freewheeling Best, dp From fbar at footils.org Tue May 23 20:43:40 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue May 23 20:43:49 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060523161807.GB12477@pomme.anchorland.local> References: <20060522125944.GA7066@pomme.anchorland.local> <20060522133426.GS5869@fliwatut.scifi> <20060523161807.GB12477@pomme.anchorland.local> Message-ID: <20060524004340.GA12329@fliwatut.scifi> Hallo, Paul Brossier hat gesagt: // Paul Brossier wrote: > On Mon, May 22, 2006 at 03:34:27PM +0200, Frank Barknecht wrote: > > Minor nitpick: Generally help-patches in Pd nowadays follow the naming > > convention: "NAME-help.pd" instead of "help-NAME.pd" as in the > > aubio-distribution. Maybe you can change this in future versions. > > Ah, thanks for noticing! This will be fixed in the next release. Thank you. Having the name in front of the help file's name makes it easier to find the help patch for a certain external quicker. You should then be able to omit the call to "class_sethelpsymbol" in the Pd externals altogether, as "NAME-help.pd" is the default name anyways. (If the default changes again in the future - unlikely -, you wouldn't need to update the source, you could just rename the help file.) Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From aaron at akjmusic.com Tue May 23 15:46:47 2006 From: aaron at akjmusic.com (Aaron Krister Johnson) Date: Tue May 23 20:47:18 2006 Subject: [linux-audio-dev] logos wanted In-Reply-To: <4473781A.5090708@woh.rr.com> References: <4473781A.5090708@woh.rr.com> Message-ID: <200605231946.47416.aaron@akjmusic.com> Dave, While you're at it, can you mention that I'm starting to build some audio packages for Slackware-10.2, and they are available on linuxpackages.net I'm doing this since the demise of audioslack.com, however, supposedly it will rise again soon..... Any Slackware users have any package requests, or want to volunteer making some packages? The new audioslack guy said he wouldn't mind some help... Best, Aaron. On Tuesday 23 May 2006 9:01 pm, Dave Phillips wrote: > Greetings: > > I'm spiffing up the Linux soundapps site, adding logos to the front > page. I'm missing logos for Ardour and Rosegarden, are they around > anywhere ? > > I'll try to update the site tonight, I'll be happy to add any new > logos as I receive them. Please send them to me off-list, thanks. > > I have these already: > > linuxaudio.org > LAD > LAU > Demudi > dynebolic > Planet CCRMA > APODIO > Studio To Go > Musix > 64Studio > JackLab > LAM > ALSA > JACK > LADSPA > FST > Audacity > ReZound > ecasound > Sweep > Hydrogen > CLAM > Csound > RTCmix > LinuxSampler > MusE > seq24 > BEAST > xiph.org > GRip > Freewheeling > > Best, > > dp From jwoithe at physics.adelaide.edu.au Tue May 23 22:50:33 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Tue May 23 22:43:31 2006 Subject: [linux-audio-dev] [ANN] realtime-lsm 0.8.6 available via SourceForge In-Reply-To: <20060523102015.C14BC183FAD2@music.columbia.edu> from "linux-audio-dev-request@music.columbia.edu" at May 23, 2006 06:20:15 AM Message-ID: <200605240250.k4O2oXTL000762@auster.physics.adelaide.edu.au> Jack O'Quin wrote: > The kernel developers prefer their own rlimits solution for granting > realtime privileges. Since that is their responsibility, I defer to > their feelings. Since their solution requires PAM updates which have > been very slow to appear in end-user distributions, I continue to > provide this (simpler) solution via SourceForge for those who need it. For reference there are alternative ways to gain access to the rlimits functionality which don't rely on updated PAM (or login on PAM-less systems such as Slackware). Set_rlimits, available at http://www.physics.adelaide.edu.au/~jwoithe/set_rlimits-1.2.0.tgz is one alternative and has the advantage of operating on a per-user/per-application level rather than a per-user level (ie: elevated limits are set for users/groups running specified applications only). Yes, it's slightly less convenient but it works and is arguably more secure. Regards jonathan From mdeboer at iua.upf.edu Wed May 24 11:13:52 2006 From: mdeboer at iua.upf.edu (Maarten de Boer) Date: Wed May 24 11:14:43 2006 Subject: [linux-audio-dev] crossplatform atomics Message-ID: <20060524171352.a188e881.mdeboer@iua.upf.es> Hello, I am looking for a cross-platform implementation of an atomic integer. Under Linux, a build an c++ class "atomic" around asm/atomic.h, (which I can use as if it where an int), but I'd like to have a solution that also works on Windows XP and Mac OS X. Thanks for any suggestions, Maarten From nick at focusrite.com Wed May 24 11:30:14 2006 From: nick at focusrite.com (Nick Dowell) Date: Wed May 24 11:30:26 2006 Subject: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis In-Reply-To: <4473196D.7070808@alexandredenis.net> References: <200605191527.15092.cannam@all-day-breakfast.com> <200605231058.01059.cannam@all-day-breakfast.com> <0469D69E-99E2-4F70-AC8B-72B088AE5F3B@grame.fr> <200605231211.23490.cannam@all-day-breakfast.com> <4472F810.90503@alexandredenis.net> <1148389174.5302.9.camel@localhost.localdomain> <4473196D.7070808@alexandredenis.net> Message-ID: There's always relaytool... http://autopackage.org/apbuild-relaytool.php -n On 23 May 2006, at 15:17, Alexandre DENIS wrote: > Paul Davis wrote: >> i don't believe that is true. if you link with RTLD_GLOBAL, then >> dlopen >> () followed by dlsym jack_client_open() should be all that is needed. > > Additionnaly, you'll need to link the main binary with -Wl,-- > unresolved-symbols=ignore-all which is not the cleanest thing to > do :-) > > Imho, a dlopen'ed driver for each backend is much better than > playing with ignored undefined symbols. > > -a. > > > > From jack.oquin at gmail.com Wed May 24 11:41:59 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Wed May 24 11:42:11 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <20060524171352.a188e881.mdeboer@iua.upf.es> References: <20060524171352.a188e881.mdeboer@iua.upf.es> Message-ID: On 5/24/06, Maarten de Boer wrote: > Hello, > > I am looking for a cross-platform implementation of an atomic > integer. > > Under Linux, a build an c++ class "atomic" around asm/atomic.h, > (which I can use as if it where an int), but I'd like to have a > solution that also works on Windows XP and Mac OS X. PortAudio developer Ross Bencina has started a new project to address this need, including a set of lock-free algorithms based on the atomic primitives. http://www.audiomulch.com/~rossb/code/lockfree/liblfds/ I believe this will be very useful to many audio developers. But, it is still in early stages of design. There are pointers to existing implementations in this Wiki... http://works.music.columbia.edu/LFDS -- joq From niklas.kluegel at mytum.de Wed May 24 14:18:19 2006 From: niklas.kluegel at mytum.de (=?ISO-8859-1?Q?Niklas_Kl=FCgel?=) Date: Wed May 24 14:18:29 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: References: <20060524171352.a188e881.mdeboer@iua.upf.es> Message-ID: <4474A36B.900@mytum.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jack O'Quin wrote: > On 5/24/06, Maarten de Boer wrote: > >> Hello, >> >> I am looking for a cross-platform implementation of an atomic >> integer. >> >> Under Linux, a build an c++ class "atomic" around asm/atomic.h, >> (which I can use as if it where an int), but I'd like to have a >> solution that also works on Windows XP and Mac OS X. > > > PortAudio developer Ross Bencina has started a new project to > address this need, including a set of lock-free algorithms based on > the atomic primitives. > > http://www.audiomulch.com/~rossb/code/lockfree/liblfds/ > > I believe this will be very useful to many audio developers. But, > it is still in early stages of design. There are pointers to > existing implementations in this Wiki... > > http://works.music.columbia.edu/LFDS if you feel like having a dependency to the qt-core libs you might consider using their atomic low-level-operations. so long... nuekki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEdKNr+k24EnBNzsMRAgfEAJ0fDPKoYJEplKTDNV6AJ63E3QjF3wCfTMQr s7R5O9c7DJHg6GTDS7aZcV8= =Mebj -----END PGP SIGNATURE----- From jens.andreasen at chello.se Wed May 24 20:24:23 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed May 24 20:24:33 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <4474A36B.900@mytum.de> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> Message-ID: <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> > >> I am looking for a cross-platform implementation of an atomic > >> integer. sizeof(int) is your friend int speedy; as well, since int is defined to be the fastest integer on your platform of choice. -- From jens.andreasen at chello.se Wed May 24 20:44:50 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed May 24 20:45:01 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> On Thu, 2006-05-25 at 02:24 +0200, Jens M Andreasen wrote: > > >> I am looking for a cross-platform implementation of an atomic > > >> integer. > > sizeof(int) is your friend > > int speedy; as well, since int is defined to be the fastest integer on > your platform of choice. > Uhmm, I was reliying on you using a contemporary implementation. For a philosophical discussion you might prefer to look elsewhere -- mvh // Jens M Andreasen From paul at linuxaudiosystems.com Wed May 24 20:58:34 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed May 24 20:58:47 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1148518714.3150.0.camel@localhost.localdomain> On Thu, 2006-05-25 at 02:44 +0200, Jens M Andreasen wrote: > On Thu, 2006-05-25 at 02:24 +0200, Jens M Andreasen wrote: > > > >> I am looking for a cross-platform implementation of an atomic > > > >> integer. > > > > sizeof(int) is your friend > > > > int speedy; as well, since int is defined to be the fastest integer on > > your platform of choice. > > > Uhmm, I was reliying on you using a contemporary implementation. For a > philosophical discussion you might prefer to look elsewhere not sure what you mean, but on sparcs, int writes are not atomic unless you only use the lower 24 bits. From jens.andreasen at chello.se Wed May 24 21:23:43 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed May 24 21:23:54 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148518714.3150.0.camel@localhost.localdomain> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> Message-ID: <1148520223.9544.141.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-05-24 at 20:58 -0400, Paul Davis wrote: > On Thu, 2006-05-25 at 02:44 +0200, Jens M Andreasen wrote: > > On Thu, 2006-05-25 at 02:24 +0200, Jens M Andreasen wrote: > > > > >> I am looking for a cross-platform implementation of an atomic > > > > >> integer. > > > > > > sizeof(int) is your friend > > > > > > int speedy; as well, since int is defined to be the fastest integer on > > > your platform of choice. > > > > > Uhmm, I was reliying on you using a contemporary implementation. For a > > philosophical discussion you might prefer to look elsewhere > > not sure what you mean, but on sparcs, int writes are not atomic unless > you only use the lower 24 bits. > Right, I tried to retract some of what I said that is only valid for the cheap stuff available today BTW: What sparc? I came in with 64bit datapaths ... > > -- From mdeboer at iua.upf.edu Thu May 25 05:32:52 2006 From: mdeboer at iua.upf.edu (Maarten de Boer) Date: Thu May 25 05:33:41 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148518714.3150.0.camel@localhost.localdomain> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> Message-ID: <20060525113252.a1c16f07.mdeboer@iua.upf.es> > not sure what you mean, but on sparcs, int writes are not atomic unless > you only use the lower 24 bits. right, this is exactly the point! 32 bits int might be atomic on a certain platform, but i have no idea about many others. in the meantime, a part from joq suggestion of LFDS, and niklas mention of qt-core libs, i also came accross th glib atomic operations http://developer.gnome.org/doc/API/2.0/glib/glib-Atomic-Operations.html and the MacOSX atomic functions as in CarbonCore/DriverSynchronization.h maarten From kvehmanen at eca.cx Thu May 25 12:57:55 2006 From: kvehmanen at eca.cx (Kai Vehmanen) Date: Thu May 25 13:01:01 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148518714.3150.0.camel@localhost.localdomain> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> Message-ID: On Wed, 24 May 2006, Paul Davis wrote: >>> sizeof(int) is your friend > not sure what you mean, but on sparcs, int writes are not atomic unless > you only use the lower 24 bits. Does someone have a good reference on this? I think the writes just are not atomic, but you can use some tricks [1] to implement atomic behaviour by spinning until the operation succeeds. [1] http://www.freepatentsonline.com/5666546.html?highlight=5434995 .. I'm not sure maybe this is just one variation... But, reading the Linux 2.6.16.17 code for sparc (atomic.h and atomic.S), only the writes are protected, not reads. So as long as you have only one writer, you should be safe. Also, the 24bit limitation only applies if you are using the low 8bits for spinning. Anyways, a good (accurate and available online) reference for this would be nice to have, to be 100% sure before making any architectural decisions. For me, I'd be happy to just exclude these platforms, or use mutexes as a crude workaround on the affected platforms (assuming there're only few of them). Cross-platform atomic integer operations would be nice, but you can do quite a lot with just atomic read/writes, which most of the platforms already provide for 'int's. For example, these are sufficient to implement a simple one-writer-one-reader lock-free queue (which is necessary in most audio apps). OTOH, it is probably wise to explicitly mark all code where ints are assumed to be atomic w.r.t. read/writes (or any other non-standard properties). Especially if sparc-style atomic properties become more widely used later on... -- links, my public keys, etc at http://eca.cx/kv From rlrevell at joe-job.com Thu May 25 13:28:39 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu May 25 13:28:53 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> Message-ID: <1148578120.31038.3.camel@mindpipe> On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: > Does someone have a good reference on this? I think the writes just > are not atomic, but you can use some tricks [1] to implement atomic > behaviour by spinning until the operation succeeds. Do we still care about 32 bit sparc? Lee From loki.davison at gmail.com Thu May 25 19:24:06 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu May 25 19:24:13 2006 Subject: [linux-audio-dev] Re: crossplatform atomics In-Reply-To: <1148578120.31038.3.camel@mindpipe> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> <1148578120.31038.3.camel@mindpipe> Message-ID: On 5/26/06, Lee Revell wrote: > On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: > > Does someone have a good reference on this? I think the writes just > > are not atomic, but you can use some tricks [1] to implement atomic > > behaviour by spinning until the operation succeeds. > > Do we still care about 32 bit sparc? > > Lee Doing audio on a 32 bit sparc.... mmm. Why not buy a spend 150 euro and by a 2-3 ghz intel/amd machine new? From dlphillips at woh.rr.com Thu May 25 22:20:58 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu May 25 22:15:24 2006 Subject: [linux-audio-dev] Linux soundapps pages updated Message-ID: <4476660A.6070800@woh.rr.com> Greetings: It's the Pretty Pictures edition, just in time for the summer fashion season : http://linuxsound.atnet.at (Europe) http://linuxsound.jp (Japan) http://linux-sound.org (USA) Best, dp From drobilla at connect.carleton.ca Thu May 25 23:09:48 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu May 25 23:10:29 2006 Subject: [linux-audio-dev] LV2 library API Message-ID: <1148612989.31105.7.camel@DaveLap> Hi all, I've been working on a host library for LV2 plugins. It's at the point where everything is working (LV2 plugins are working in Om right now), so I'd like some feedback on the API from anyone who's interested before it gets too entrenched. The primary design goal is to be as simple and terse as possible for the host author, so if you would prefer something was different let me know. A simple (working) Jack host: http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c Doxygen documentation: http://www.scs.carleton.ca/~drobilla/files/libslv2_doc/ (Anything having to do with SLV2Property is still hairy, everything else is fair game). And no, you can't have the code yet. Steve would hang me. :) Cheers, -DR- From rj at spamatica.se Fri May 26 03:41:21 2006 From: rj at spamatica.se (Robert Jonsson) Date: Fri May 26 03:43:20 2006 Subject: [linux-audio-dev] Re: crossplatform atomics In-Reply-To: References: <20060524171352.a188e881.mdeboer@iua.upf.es> <1148578120.31038.3.camel@mindpipe> Message-ID: <200605260941.22184.rj@spamatica.se> On Friday 26 May 2006 01:24, Loki Davison wrote: > On 5/26/06, Lee Revell wrote: > > On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: > > > Does someone have a good reference on this? I think the writes just > > > are not atomic, but you can use some tricks [1] to implement atomic > > > behaviour by spinning until the operation succeeds. > > > > Do we still care about 32 bit sparc? > > > > Lee > > Doing audio on a 32 bit sparc.... mmm. Why not buy a spend 150 euro > and by a 2-3 ghz intel/amd machine new? I think the idea was that since one (old) architecture does not have atomic ints there might be more. Since I really could not care less about 32bit sparc, the more interesting question would be; is it possible that non atomic ints will crop up in future hardware designs? To me it just sounds, really, really, really, improbable. 0.02 SEK /Robert From kvehmanen at eca.cx Fri May 26 03:41:10 2006 From: kvehmanen at eca.cx (Kai Vehmanen) Date: Fri May 26 03:44:36 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <1148578120.31038.3.camel@mindpipe> References: <20060524171352.a188e881.mdeboer@iua.upf.es> <4474A36B.900@mytum.de> <1148516664.9544.126.camel@c80-216-124-251.cm-upc.chello.se> <1148517890.9544.135.camel@c80-216-124-251.cm-upc.chello.se> <1148518714.3150.0.camel@localhost.localdomain> <1148578120.31038.3.camel@mindpipe> Message-ID: On Thu, 25 May 2006, Lee Revell wrote: > On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: >> Does someone have a good reference on this? I think the writes just > Do we still care about 32 bit sparc? Not necessarily much, but I'd like to understand this fully. There might be other archs affected as well. Again looking at the Linux kernel code - for instance armv6 atomic_set needs spinning (but not for armv4)... so it's not just sparc32. There might not be _that_ many sparc32s out there, but there are over 3 billion arm cores out there. ;) But, but, even on these platforms, it's just the writes. It'd be interesting to know if there are any cases where you could be reading bogus values due to concurrent access to an 'int'. -- links, my public keys, etc at http://eca.cx/kv From annabellesgarden at yahoo.de Fri May 26 05:28:38 2006 From: annabellesgarden at yahoo.de (karsten wiese) Date: Fri May 26 05:28:46 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060522125944.GA7066@pomme.anchorland.local> Message-ID: <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> > > As usual, the source code can be found at http://aubio.piem.org/ , > and Debian packages are available from http://piem.org/debian/ . > > Feedback most appreciated! > Hi Paul, attached fixlet makes MEMSET macro expand as intended. Karsten ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de -------------- next part -------------- A non-text attachment was scrubbed... Name: aubio-0.3.0_MEMSET.patch Type: text/x-diff Size: 2029 bytes Desc: 1130238332-aubio-0.3.0_MEMSET.patch Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060526/da82c7a1/aubio-0.3.0_MEMSET.bin From krampenschiesser at freenet.de Fri May 26 05:31:53 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Fri May 26 05:32:11 2006 Subject: [linux-audio-dev] Midi Clock Message-ID: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> Hi I'm currently writing on a loop based midi sequencer. My problem is that I want to get Hardware synced via midi clock. I've read that the midi-clock signal is send 24 times in a quarter note. My sequencer is network based. So there is one time-server which sends a tcp packet with every 256 note. But when I want it to send the midi-clock signal it would be send every 2+2/3 note. Which is not possible. Do you see any solution? -- A sine curve goes off to infinity, or at least the end of the blackboard. -- Prof. Steiner From gene.heskett at verizon.net Fri May 26 06:05:56 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri May 26 06:06:07 2006 Subject: [linux-audio-dev] compiler problem? Message-ID: <4476D304.9080006@verizon.net> Greetings; Since I can't get any of the common VoIP things to work due to a lack of duplex function in my lappy's chipset, and my inability to convince the person bugtrack assigned to my bugzilla entry that its not my fault, I thought I'd try zfone next. Unforch, the first step, ./configure, fails with 2 stanza's of this: checking linux/byteorder/little_endian.h usability... no checking linux/byteorder/little_endian.h presence... yes configure: WARNING: linux/byteorder/little_endian.h: present but cannot be compiled configure: WARNING: linux/byteorder/little_endian.h: check for missing prerequisite headers? configure: WARNING: linux/byteorder/little_endian.h: see the Autoconf documentation configure: WARNING: linux/byteorder/little_endian.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/byteorder/little_endian.h: proceeding with the preprocessor's result configure: WARNING: linux/byteorder/little_endian.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------ ## configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## configure: WARNING: ## ------------------------------------------ ## checking for linux/byteorder/little_endian.h... yes checking linux/byteorder/big_endian.h usability... no checking linux/byteorder/big_endian.h presence... yes configure: WARNING: linux/byteorder/big_endian.h: present but cannot be compiled configure: WARNING: linux/byteorder/big_endian.h: check for missing prerequisite headers? configure: WARNING: linux/byteorder/big_endian.h: see the Autoconf documentation configure: WARNING: linux/byteorder/big_endian.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/byteorder/big_endian.h: proceeding with the preprocessor's result configure: WARNING: linux/byteorder/big_endian.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------ ## configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## configure: WARNING: ## ------------------------------------------ ## checking for linux/byteorder/big_endian.h... yes I've googled in vain for a solution as the make also fails later: gcc -DHAVE_CONFIG_H -I. -I. -I../config -I../include -I../bnlib/ -I../srtp/include -I../srtp/crypto/include -Wno-unused -g -O2 -c -o base32.o `test -f './base32.c' || echo './'`./base32.c In file included from ../srtp/crypto/include/datatypes.h:60, from ../srtp/crypto/include/err.h:49, from ../srtp/crypto/include/rand_source.h:49, from ../srtp/crypto/include/crypto_kernel.h:49, from ../srtp/include/srtp.h:53, from ../include/zrtp_protocol.h:13, from ../include/zrtp_types.h:184, from ./base32.c:7: /usr/include/netinet/in.h:354: error: expected declaration specifiers or ?...? before ?(? token /usr/include/netinet/in.h:354: error: expected ?)? before ??? token /usr/include/netinet/in.h:355: error: expected declaration specifiers or ?...? before ?(? token /usr/include/netinet/in.h:355: error: expected ?)? before ??? token /usr/include/netinet/in.h:357: error: expected declaration specifiers or ?...? before ?(? token /usr/include/netinet/in.h:357: error: expected ?)? before ??? token /usr/include/netinet/in.h:359: error: expected declaration specifiers or ?...? before ?(? token /usr/include/netinet/in.h:359: error: expected ?)? before ??? token ./base32.c: In function ?b2a?: ./base32.c:59: warning: comparison of distinct pointer types lacks a cast make[1]: *** [base32.o] Error 1 make[1]: Leaving directory `/usr/src/Zfone/libzrtp-0.2.0/src' make: *** [all-recursive] Error 1 This is after outputting dozens of warnings about 'too many arguments for function' Phil Zimmerman's code is usually of quite high quality... -- Cheers, Gene From dlphillips at woh.rr.com Fri May 26 07:32:14 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Fri May 26 07:26:21 2006 Subject: [linux-audio-dev] stuff I've done In-Reply-To: References: Message-ID: <4476E73E.90306@woh.rr.com> Check it out: http://www.columbia.edu/acis/history/cpemc.html Third photo from the top, it's Brad in the 80s. :) Say, whatever happened to that Mark II ? And why hasn't anyone done a plugin version of it yet ?! ;-) Best, dp Bradford Garton wrote: > Hey everyone -- > > Sorry about the multiple postings, but I figured what the heck... > > I've just put on-line a whole lot of work I've done; papers, pieces, > software, etc. Here's the link for the 2-3 people (beyond my > immediate family) who might be interested: > > http://music.columbia.edu/~brad/ > > There's a fair amount of unix/linux work scattered throughout, > including the big "My Music Book" thing I did a few years ago. > > Hope you enjoy this! > > brad > From larsl at users.sourceforge.net Fri May 26 08:10:04 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri May 26 08:10:15 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1148612989.31105.7.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> Message-ID: <1148645404.8858.0.camel@localhost> On Thu, 2006-05-25 at 23:09 -0400, Dave Robillard wrote: > Hi all, > > I've been working on a host library for LV2 plugins. It's at the point > where everything is working (LV2 plugins are working in Om right now), > so I'd like some feedback on the API from anyone who's interested before > it gets too entrenched. The primary design goal is to be as simple and > terse as possible for the host author, so if you would prefer something > was different let me know. > > A simple (working) Jack host: > http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c Is it necessary to include directly? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060526/33a6155f/attachment.bin From larsl at users.sourceforge.net Fri May 26 08:18:41 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri May 26 08:18:51 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1148612989.31105.7.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> Message-ID: <1148645921.8858.2.camel@localhost> On Thu, 2006-05-25 at 23:09 -0400, Dave Robillard wrote: > Hi all, > > I've been working on a host library for LV2 plugins. What's the license? GPL? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060526/264fb59d/attachment-0001.bin From mle+la at mega-nerd.com Fri May 26 08:25:57 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri May 26 08:26:07 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> References: <20060522125944.GA7066@pomme.anchorland.local> <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> Message-ID: <20060526222557.988a8473.mle+la@mega-nerd.com> karsten wiese wrote: > > > > As usual, the source code can be found at http://aubio.piem.org/ , > > and Debian packages are available from http://piem.org/debian/ . Errm, this looks really weird. @@ -41,7 +41,7 @@ aubio_sndfile_t * new_aubio_sndfile_ro(const char* outputname) { aubio_sndfile_t * f = AUBIO_NEW(aubio_sndfile_t); SF_INFO sfinfo; - AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo)); + AUBIO_MEMSET(&sfinfo, 0, sfinfo); sfinfo.format = 0; f->handle = sf_open (outputname, SFM_READ, &sfinfo); Are you sure you don't have diff direction wrong? If you have a macro called X_MEMSET with very similar arguments to the standard C function, the macro should have the same symanics as the function it wraps. If you don't, you will confuse people. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Lumping configuration data, security data, kernel tuning parameters, etc. into one monstrous fragile binary data structure is really dumb." - David F. Skoll From mle+la at mega-nerd.com Fri May 26 08:27:42 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri May 26 08:27:53 2006 Subject: [linux-audio-dev] compiler problem? In-Reply-To: <4476D304.9080006@verizon.net> References: <4476D304.9080006@verizon.net> Message-ID: <20060526222742.1ff5cd0f.mle+la@mega-nerd.com> Gene Heskett wrote: > Greetings; > > Since I can't get any of the common VoIP things to work due to a lack of > duplex function in my lappy's chipset, and my inability to convince the > person bugtrack assigned to my bugzilla entry that its not my fault, I > thought I'd try zfone next. > > Unforch, the first step, ./configure, fails with 2 stanza's of this: > checking linux/byteorder/little_endian.h usability... no > checking linux/byteorder/little_endian.h presence... yes > configure: WARNING: linux/byteorder/little_endian.h: present but cannot > be compiled Is this a device driver or a user space program. Basically no user space program other than libc should be using kernel header files. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ `[Microsoft] are in the business of giving customers exactly what they ask for, which sounds like a nice idea until you realize that most Microsoft customers are idiots.' --- Eugene O'Neil on comp.os.linux.development.system From jens.andreasen at chello.se Fri May 26 09:18:59 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri May 26 09:19:16 2006 Subject: [linux-audio-dev] Midi Clock In-Reply-To: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> Message-ID: <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2006-05-26 at 11:31 +0200, krampenschiesser@freenet.de wrote: > Hi I'm currently writing on a loop based midi sequencer. > My problem is that I want to get Hardware synced via midi clock. > I've read that the midi-clock signal is send 24 times in a quarter note. > My sequencer is network based. > So there is one time-server which sends a tcp packet with every 256 note. > But when I want it to send the midi-clock signal it would be send every 2+2/3 note. Which is not possible. > Do you see any solution? > Change the time-server resolution to 240/note? -- From annabellesgarden at yahoo.de Fri May 26 09:40:42 2006 From: annabellesgarden at yahoo.de (karsten wiese) Date: Fri May 26 09:41:07 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060526222557.988a8473.mle+la@mega-nerd.com> Message-ID: <20060526134042.36831.qmail@web26501.mail.ukl.yahoo.com> > - AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo)); > + AUBIO_MEMSET(&sfinfo, 0, sfinfo); > sfinfo.format = 0; > > f->handle = sf_open (outputname, SFM_READ, &sfinfo); > > Are you sure you don't have diff direction wrong? > yes, given how AUBIO_MEMSET ist defined: #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) before the patch above example would expand to memset(&sfinfo, 0, sizeof(sizeof (sfinfo))); which becomes memset(&sfinfo, 0, sizeof(size_t)); what is not what we want here:-) Karsten ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From piem at altern.org Fri May 26 09:43:15 2006 From: piem at altern.org (Paul Brossier) Date: Fri May 26 09:45:52 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060526222557.988a8473.mle+la@mega-nerd.com> References: <20060522125944.GA7066@pomme.anchorland.local> <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> <20060526222557.988a8473.mle+la@mega-nerd.com> Message-ID: <20060526134315.GA1203@pomme.anchorland.local> On Fri, May 26, 2006 at 10:25:57PM +1000, Erik de Castro Lopo wrote: > karsten wiese wrote: > > > > > > > As usual, the source code can be found at http://aubio.piem.org/ , > > > and Debian packages are available from http://piem.org/debian/ . > > Errm, this looks really weird. > > @@ -41,7 +41,7 @@ > aubio_sndfile_t * new_aubio_sndfile_ro(const char* outputname) { > aubio_sndfile_t * f = AUBIO_NEW(aubio_sndfile_t); > SF_INFO sfinfo; > - AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo)); > + AUBIO_MEMSET(&sfinfo, 0, sfinfo); > sfinfo.format = 0; > > f->handle = sf_open (outputname, SFM_READ, &sfinfo); > > Are you sure you don't have diff direction wrong? no, stefan's patch is correct. the macro reads: #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) > If you have a macro called X_MEMSET with very similar arguments > to the standard C function, the macro should have the same > symanics as the function it wraps. If you don't, you will confuse > people. well, indeed i got confused myself. this also explains the 'strange' sndfile behavior i found on powerpc, wrongly 'fixed' with the sfinfo.format = 0 line. thanks for reporting this Stefan, it will be fixed soon. bye, Paul From gene.heskett at verizon.net Fri May 26 09:56:22 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri May 26 09:56:29 2006 Subject: [linux-audio-dev] compiler problem? In-Reply-To: <20060526222742.1ff5cd0f.mle+la@mega-nerd.com> References: <4476D304.9080006@verizon.net> <20060526222742.1ff5cd0f.mle+la@mega-nerd.com> Message-ID: <44770906.2080208@verizon.net> Erik de Castro Lopo wrote: > Gene Heskett wrote: > >> Greetings; >> >> Since I can't get any of the common VoIP things to work due to a lack of >> duplex function in my lappy's chipset, and my inability to convince the >> person bugtrack assigned to my bugzilla entry that its not my fault, I >> thought I'd try zfone next. >> >> Unforch, the first step, ./configure, fails with 2 stanza's of this: >> checking linux/byteorder/little_endian.h usability... no >> checking linux/byteorder/little_endian.h presence... yes >> configure: WARNING: linux/byteorder/little_endian.h: present but cannot >> be compiled > > Is this a device driver or a user space program. > > Basically no user space program other than libc should be using > kernel header files. > > Erik I don't have a real good understanding of it, but I believe this wedges itself between the VoIP app, and the drivers. That file appears to exist on this box in the usual location, and in the kernel src trees: root@diablo libzrtp-0.2.0]# locate big_endian.h /usr/include/linux/byteorder/big_endian.h /usr/src/kernels/2.6.16-1.2096_FC5-i686/include/linux/byteorder/big_endian.h /usr/src/kernels/2.6.16-1.2111_FC5-i686/include/linux/byteorder/big_endian.h /usr/src/kernels/2.6.16-1.2118_FC5-i686/include/linux/byteorder/big_endian.h /usr/src/kernels/2.6.16-1.2122_FC5-i686/include/linux/byteorder/big_endian.h In going thru the config.log, the path it used was /usr/include/linux/byteorder, and there doesn't seem to be any reference to a 'uname -r' to determine the path to the includes, so this doesn't appear to be a valid conclusion on your part that it was using kernel headers. However, I'd also note that the kernel versions of these *endian files are both over a kilobyte larger and several years newer. As this is an up 2 date, from scratch FC5 install, I was surprised to see files dated 2001 in the /usr/includes tree. -- Cheers, Gene From krampenschiesser at freenet.de Fri May 26 10:46:49 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Fri May 26 10:47:03 2006 Subject: [linux-audio-dev] Midi Clock In-Reply-To: <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060526164649.377c7259.krampenschiesser@freenet.de> On Fri, 26 May 2006 15:18:59 +0200 Jens M Andreasen wrote: > Change the time-server resolution to 240/note? But then my sequencers would get out of sync. -- In the beginning there was nothing. And the Lord said "Let There Be Light!" And still there was nothing, but at least now you could see it. From drobilla at connect.carleton.ca Fri May 26 12:54:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri May 26 12:54:33 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1148645404.8858.0.camel@localhost> References: <1148612989.31105.7.camel@DaveLap> <1148645404.8858.0.camel@localhost> Message-ID: <1148662453.29421.0.camel@DaveLap> On Fri, 2006-05-26 at 14:10 +0200, Lars Luthman wrote: > On Thu, 2006-05-25 at 23:09 -0400, Dave Robillard wrote: > > Hi all, > > > > I've been working on a host library for LV2 plugins. It's at the point > > where everything is working (LV2 plugins are working in Om right now), > > so I'd like some feedback on the API from anyone who's interested before > > it gets too entrenched. The primary design goal is to be as simple and > > terse as possible for the host author, so if you would prefer something > > was different let me know. > > > > A simple (working) Jack host: > > http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c > > Is it necessary to include directly? Oh right, forgot about that. Nope. *Updated* -DR- From drobilla at connect.carleton.ca Fri May 26 12:54:31 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri May 26 12:55:15 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1148645921.8858.2.camel@localhost> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> Message-ID: <1148662471.29421.2.camel@DaveLap> On Fri, 2006-05-26 at 14:18 +0200, Lars Luthman wrote: > On Thu, 2006-05-25 at 23:09 -0400, Dave Robillard wrote: > > Hi all, > > > > I've been working on a host library for LV2 plugins. > > What's the license? GPL? Yes. -DR- From rlrevell at joe-job.com Fri May 26 13:11:15 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri May 26 13:31:47 2006 Subject: [linux-audio-dev] compiler problem? In-Reply-To: <4476D304.9080006@verizon.net> References: <4476D304.9080006@verizon.net> Message-ID: <1148663476.31038.67.camel@mindpipe> On Fri, 2006-05-26 at 05:05 -0500, Gene Heskett wrote: > Greetings; > > Since I can't get any of the common VoIP things to work due to a lack of > duplex function in my lappy's chipset, and my inability to convince the > person bugtrack assigned to my bugzilla entry that its not my fault, I > thought I'd try zfone next. Um, you never answered tiwai's last question. "Grr, you make the things too complex. Let's sort out the thing straight. The duplex problem and the inproper recording are different things. First, check whether both non-duplex playback and recording work properly. For checking playback, you can use speaker-test program in alsa-utils package, too. Run "speaker-test -c2 -tw", for example. As I mentioned, you can test recording of the played stream by setting "Capture Source" to "Mix". It needs no extra hardware setup, so no hard work after running a full marathon. If the full-duplex works by this way, skype and other programs should work as well -- as long as you set up the mixer correctly. Anyway, don't use audacity or whatever apps might be using OSS emulation for tests. They can't be used as references. Use basic tools included in ALSA packages for primary tests." We have to debug one thing at a time, and using the simplest possible tools, rather than some huge VOIP app that goes through the OSS layer. If you are not interested in debugging it further I will close the report. Lee From radarsat1 at gmail.com Fri May 26 17:00:21 2006 From: radarsat1 at gmail.com (Steve) Date: Fri May 26 17:00:28 2006 Subject: [linux-audio-dev] Midi Clock In-Reply-To: <20060526164649.377c7259.krampenschiesser@freenet.de> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> Message-ID: <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> Hi, Do you mean that you are sending one packet after 256 notes have played? In that case, I assume you are using it to periodically re-synchronize independant clocks. If that's the case, the local computer should be used to generate the MIDI clock according to its own clock. The local computer's own clock can then by re-synchronized periodically with the remote computer, which will automatically also re-sync the local MIDI clock signal. Does that make sense? Am I correct in understanding that MIDI is not being sent over the TCP connection? Steve On 5/26/06, krampenschiesser@freenet.de wrote: > On Fri, 26 May 2006 15:18:59 +0200 > Jens M Andreasen wrote: > > Change the time-server resolution to 240/note? > But then my sequencers would get out of sync. > > -- > In the beginning there was nothing. And the Lord said "Let There Be Light!" > And still there was nothing, but at least now you could see it. > From mle+la at mega-nerd.com Fri May 26 17:50:32 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri May 26 17:50:42 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060526134315.GA1203@pomme.anchorland.local> References: <20060522125944.GA7066@pomme.anchorland.local> <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> <20060526222557.988a8473.mle+la@mega-nerd.com> <20060526134315.GA1203@pomme.anchorland.local> Message-ID: <20060527075032.72ae51d3.mle+la@mega-nerd.com> Paul Brossier wrote: > On Fri, May 26, 2006 at 10:25:57PM +1000, Erik de Castro Lopo wrote: > > karsten wiese wrote: > > > > > > > > > > As usual, the source code can be found at http://aubio.piem.org/ , > > > > and Debian packages are available from http://piem.org/debian/ . > > > > Errm, this looks really weird. > > > > @@ -41,7 +41,7 @@ > > aubio_sndfile_t * new_aubio_sndfile_ro(const char* outputname) { > > aubio_sndfile_t * f = AUBIO_NEW(aubio_sndfile_t); > > SF_INFO sfinfo; > > - AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo)); > > + AUBIO_MEMSET(&sfinfo, 0, sfinfo); > > sfinfo.format = 0; > > > > f->handle = sf_open (outputname, SFM_READ, &sfinfo); > > > > Are you sure you don't have diff direction wrong? > > no, stefan's patch is correct. the macro reads: > > #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) !!!!!!!! What compiler are you using that didn't call SF_INFO sfinfo; memset (&sfinfo, 0, sfinfo) ; an error? Even without any warnings turned on, gcc-3.3 and gcc-4.0 refuse to compile this and give an error "incompatible type for argument 3 of `memset'". > this also explains the 'strange' > sndfile behavior i found on powerpc, wrongly 'fixed' with the > sfinfo.format = 0 line. No it doesn't. Every compiler I can find refuses to compile the above line because it simply doesn't make sense. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Moore's Law: hardware speed doubles every 18 months Gates' Law: software speed halves every 18 months From mle+la at mega-nerd.com Fri May 26 17:55:08 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri May 26 17:55:16 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060526134042.36831.qmail@web26501.mail.ukl.yahoo.com> References: <20060526222557.988a8473.mle+la@mega-nerd.com> <20060526134042.36831.qmail@web26501.mail.ukl.yahoo.com> Message-ID: <20060527075508.4d6b4f9d.mle+la@mega-nerd.com> karsten wiese wrote: > yes, given how AUBIO_MEMSET ist defined: > #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) > > before the patch above example would expand to > memset(&sfinfo, 0, sizeof(sizeof (sfinfo))); > which becomes > memset(&sfinfo, 0, sizeof(size_t)); > what is not what we want here:-) Ahhhh of course! I missed that. I therefore repeat my suggestion that having a macro which has a name similar to that of an ISO C standard function but diffrent behaviour is a really bad idea. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "We have fifty million Muslims in Europe. There are signs that Allah will grant Islam victory in Europe - without swords, without guns, without conquests. The fifty million Muslims of Europe will turn it into a Muslim continent within a few decades." -- Libyan leader Mu'ammar Al-Qadhafi http://www.memritv.org/Transcript.asp?P1=1121 From krampenschiesser at freenet.de Fri May 26 19:31:11 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Fri May 26 19:31:20 2006 Subject: [linux-audio-dev] Midi Clock In-Reply-To: <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> Message-ID: <20060527013111.754a7b83.krampenschiesser@freenet.de> On Fri, 26 May 2006 17:00:21 -0400 Steve wrote: > Hi, > > Do you mean that you are sending one packet after 256 notes have played? No I send one packet for each 1/256 note. Therefore only the timer needs to be a realtime process and the actual software sequencers don't need to. > In that case, I assume you are using it to periodically re-synchronize > independant clocks. If that's the case, the local computer should be > used to generate the MIDI clock according to its own clock. The local > computer's own clock can then by re-synchronized periodically with the > remote computer, which will automatically also re-sync the local MIDI > clock signal. > > Does that make sense? Well I didn't got this part right now, perhaps it's too late. But I solved my problem. As I send a packet with each 1/256 note to my software sequencers I was caught in the thought about 1 tact so 256/256. But this is not nessesary as I could send the midi clock independently with just another integer as counter int the for loop. I don't expect that you understand this right now, but I write this if another person could have the same problem. > Am I correct in understanding that MIDI is not being sent over the TCP > connection? No I use TCP to sync my software sequencers and want the midi clock to sync any hardware. Thanks for the help! I should sleep right now. Christian -- I am not an Economist. I am an honest man! -- Paul McCracken From gene.heskett at verizon.net Fri May 26 20:06:55 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri May 26 20:07:03 2006 Subject: [linux-audio-dev] compiler problem? In-Reply-To: <1148663476.31038.67.camel@mindpipe> References: <4476D304.9080006@verizon.net> <1148663476.31038.67.camel@mindpipe> Message-ID: <4477981F.8000400@verizon.net> Lee Revell wrote: > On Fri, 2006-05-26 at 05:05 -0500, Gene Heskett wrote: >> Greetings; >> >> Since I can't get any of the common VoIP things to work due to a lack of >> duplex function in my lappy's chipset, and my inability to convince the >> person bugtrack assigned to my bugzilla entry that its not my fault, I >> thought I'd try zfone next. > > Um, you never answered tiwai's last question. So I'll repeat that last reply, which may not have ended up where it should have, but this is a little more public. > "Grr, you make the things too complex. Let's sort out the thing > straight. > > The duplex problem and the inproper recording are different things. > First, check whether both non-duplex playback and recording work > properly. > > For checking playback, you can use speaker-test program in alsa-utils > package, too. Run "speaker-test -c2 -tw", for example. This works, PROVIDED its the last thing started. If started before the arecord or audacity recording, then arecord and audacity are denied access to the device. However if audicity making a recording is started first, then the recording works fine and the speaker-test also works fine. If audacity's recording is stopped while speaker-test is running, then speaker-test grabs it all and audacity is once again locked out of accessing the device. > As I mentioned, you can test recording of the played stream by setting > "Capture Source" to "Mix". It needs no extra hardware setup, so no hard > work after running a full marathon. Capture source in this case and in the above tests is the bottom of the slider, red 'led' in kmix, and it was set to mic. > If the full-duplex works by this way, skype and other programs should > work as well -- as long as you set up the mixer correctly. As shown above, it doesn't unless things are started in a specific order, which in the case of skype at least, I have zero control over. I assume because it opens the two paths to the device in the wrong order or something. The bottom line is that skype|ekiga, neither one works in that I cannot hear the other party, while I am crystal clear to the other party. I'm aware that the tests seem to indicate the reverse is true, but the errors reported in the case of starting speaker-test, and then running audacity, are different. As far as doing a recording using arecord, from the example in the manpage: [root@diablo ~]# arecord -d 10 -f cd -t wav -D copy foobar.wav ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM copy arecord: main:547: audio open error: No such file or directory This is while speaker-test is running. But stopping it does not change anything: [root@diablo ~]# arecord -d 30 -f cd -t wav -D copy foobar.wav ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM copy arecord: main:547: audio open error: No such file or directory So obviously there is something fubar in that command line. With it stopped, audacity can record ok, but cannot simultaniously playback either the track just made, or a different one, exhibiting the same symptoms as skype/ekiga, but actually worse in that the playback obviously falls way behind itself. > > Anyway, don't use audacity or whatever apps might be using OSS emulation > for tests. They can't be used as references. Use basic tools included > in ALSA packages for primary tests." I was not aware that audacity was an OSS aplication. > We have to debug one thing at a time, and using the simplest possible > tools, rather than some huge VOIP app that goes through the OSS layer. > If you are not interested in debugging it further I will close the > report. Oh I'm interested, but busier than that famous cat on a tin roof since wednesday morning, when we used the biggest crane I've ever seen up close (and it could have been 6 feet taller, but at 182 feet it was all used up & we had to re-rig the lift) to pick a 6 bay superturnstile antenna sized for US channel 8 broadcasting, out of the top of the tower and laid all 55 feet and about 2.5 tons of it, in a pair of cradles I made to hold it about 4 feet off the ground while I try and find suitable 7/8" 50 ohm air semi rigid coax to repair 4 of the 24 such coax lines on it that have been damaged by poor installation handling years ago when it was moved to here, and 52 years exposure to the weather. Pretty it ain't. Now I'll have about 3 days to play as the majority of the suppliers of such stuff are taking a long 3 day weekend off now, leaving me with only the usual stuff to do. -- Cheers, Gene From patrickkidd.lists at gmail.com Fri May 26 21:59:06 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Fri May 26 21:59:17 2006 Subject: [linux-audio-dev] Midi Clock In-Reply-To: <20060527013111.754a7b83.krampenschiesser@freenet.de> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> Message-ID: <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> Take a look at OSC. It assumes that all computers' clocks are synced via ntp, which is more than adequate to ensure its 64-bit fixed point timestamps are accurate. This makes the programming easier and more reliable, as you only have to program to your local clock. Relying on an Ethernet LAN for heartbeat-style clock syncing is never a good idea, as the MIDI specification describes (you don't see a Roland keyboard assembling a TCP stack on its MIDI port, for example). OSC does not define a transport, so you may use TCP or UDP or whatever you want, as many others do. I highly recommend this as a solution for you. On 5/26/06, krampenschiesser@freenet.de wrote: > On Fri, 26 May 2006 17:00:21 -0400 > Steve wrote: > > > Hi, > > > > Do you mean that you are sending one packet after 256 notes have played? > No I send one packet for each 1/256 note. Therefore only the timer needs to be a realtime process and the actual software sequencers don't need to. > > In that case, I assume you are using it to periodically re-synchronize > > independant clocks. If that's the case, the local computer should be > > used to generate the MIDI clock according to its own clock. The local > > computer's own clock can then by re-synchronized periodically with the > > remote computer, which will automatically also re-sync the local MIDI > > clock signal. > > > > Does that make sense? > Well I didn't got this part right now, perhaps it's too late. > But I solved my problem. > As I send a packet with each 1/256 note to my software sequencers I was caught in the thought about 1 tact so 256/256. > But this is not nessesary as I could send the midi clock independently with just another integer as counter int the for loop. > I don't expect that you understand this right now, but I write this if another person could have the same problem. > > Am I correct in understanding that MIDI is not being sent over the TCP > > connection? > No I use TCP to sync my software sequencers and want the midi clock to sync any hardware. > > Thanks for the help! > I should sleep right now. > Christian > > -- > I am not an Economist. I am an honest man! > -- Paul McCracken > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From piem at altern.org Sat May 27 05:17:47 2006 From: piem at altern.org (Paul Brossier) Date: Sat May 27 05:17:56 2006 Subject: [linux-audio-dev] [ANN] aubio 0.3.0 In-Reply-To: <20060527075032.72ae51d3.mle+la@mega-nerd.com> References: <20060522125944.GA7066@pomme.anchorland.local> <20060526092838.23395.qmail@web26506.mail.ukl.yahoo.com> <20060526222557.988a8473.mle+la@mega-nerd.com> <20060526134315.GA1203@pomme.anchorland.local> <20060527075032.72ae51d3.mle+la@mega-nerd.com> Message-ID: <20060527091747.GA5673@pomme.anchorland.local> On Sat, May 27, 2006 at 07:50:32AM +1000, Erik de Castro Lopo wrote: > !!!!!!!! > > What compiler are you using that didn't call > > SF_INFO sfinfo; > memset (&sfinfo, 0, sfinfo) ; > > an error? err, as Stefan said above, the macro would expand: SF_INFO sfinfo; memset (&sfinfo, 0, sizeof(sizeof(sfinfo))) ; which is not wrong but doesn't do what was intended. > Even without any warnings turned on, gcc-3.3 and gcc-4.0 refuse to > compile this and give an error "incompatible type for argument 3 of > `memset'". No syntax error here. And aubio compiles with -Wall -Werror. :) I agree with following memset syntax. the applied patch reads: -#define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) +#define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,_t) I also removed the sfinfo.format = 0 workaround in sndfile.c and confirmed the bug was gone. for the record, the error was: Unable to open input file /path/to/file.wav. Error. Bad format field in SF_INFO struct when openning a RAW file for read. Segmentation fault occuring occasionally when opening multiple files. bye, Paul From annabellesgarden at yahoo.de Sat May 27 05:48:38 2006 From: annabellesgarden at yahoo.de (karsten wiese) Date: Sat May 27 05:48:49 2006 Subject: [linux-audio-dev] [PATCH] aubio 0.3.0 makes abionotes work *) with jack & alsa_seq Message-ID: <20060527094838.55189.qmail@web26501.mail.ukl.yahoo.com> hi attached patch includes MEMSET fixlet from yesterday. it adds err subtracts pthread_* calls from aubio_midi_direct_output(). those did block here. and aren't anyhow needed in aubio_midi_direct_output(), i think. karsten *) here ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de -------------- next part -------------- A non-text attachment was scrubbed... Name: aubio-0.3.0_kw.patch Type: text/x-diff Size: 3788 bytes Desc: 4138987443-aubio-0.3.0_kw.patch Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060527/bd516e3a/aubio-0.3.0_kw.bin From paulgfx at yahoo.com Sat May 27 07:49:43 2006 From: paulgfx at yahoo.com (Paul) Date: Sat May 27 07:49:50 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware Message-ID: <20060527114943.6711.qmail@web52205.mail.yahoo.com> Hi. I rewrote the experimental time-stretching software (discussed in linux-audio-user mailinglist in "How can I time-stretch the sound like this" topic ) and I put it here: http://hypermammut.sourceforge.net/src/paulstretch/ Please listen to audio examples here (with 20x stretching): http://hypermammut.sourceforge.net/src/paulstretch/example/ The algorithm is simple and it's described into the readme.txt from the archive. There is room for improovements to avoid over-smoothing (I wrote in readme.txt how I think that is possible to do). Please tell me your opinion about it. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From petter.sundlof at findus.dhs.org Sat May 27 08:03:10 2006 From: petter.sundlof at findus.dhs.org (=?ISO-8859-1?Q?Petter_Sundl=F6f?=) Date: Sat May 27 08:03:24 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware In-Reply-To: <20060527114943.6711.qmail@web52205.mail.yahoo.com> References: <20060527114943.6711.qmail@web52205.mail.yahoo.com> Message-ID: <44783FFE.8030503@findus.dhs.org> Very nice! I like the quality. This should be integrated into Ardour =) Paul wrote: > Hi. > I rewrote the experimental time-stretching software > (discussed in linux-audio-user mailinglist in "How can > I time-stretch the sound like this" topic ) and I put > it > here: > http://hypermammut.sourceforge.net/src/paulstretch/ > > Please listen to audio examples here (with 20x > stretching): > http://hypermammut.sourceforge.net/src/paulstretch/example/ > > The algorithm is simple and it's described into the > readme.txt from the archive. There is room for > improovements to avoid over-smoothing (I wrote in > readme.txt how I think that is possible to do). > > Please tell me your opinion about it. > > Paul > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From paul at linuxaudiosystems.com Sat May 27 08:47:56 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat May 27 08:48:10 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware In-Reply-To: <44783FFE.8030503@findus.dhs.org> References: <20060527114943.6711.qmail@web52205.mail.yahoo.com> <44783FFE.8030503@findus.dhs.org> Message-ID: <1148734076.23738.64.camel@localhost.localdomain> On Sat, 2006-05-27 at 14:03 +0200, Petter Sundl?f wrote: > Very nice! I like the quality. > This should be integrated into Ardour =) next week :) From piem at altern.org Sat May 27 10:09:12 2006 From: piem at altern.org (Paul Brossier) Date: Sat May 27 10:10:24 2006 Subject: [linux-audio-dev] Re: [PATCH] aubio 0.3.0 makes abionotes work *) with jack & alsa_seq In-Reply-To: <20060527094838.55189.qmail@web26501.mail.ukl.yahoo.com> References: <20060527094838.55189.qmail@web26501.mail.ukl.yahoo.com> Message-ID: <20060527140912.GA27993@pomme.anchorland.local> Hi Stefan, On Sat, May 27, 2006 at 11:48:38AM +0200, karsten wiese wrote: > hi > > attached patch includes MEMSET fixlet from yesterday. > it adds err subtracts pthread_* calls from > aubio_midi_direct_output(). > those did block here. thanks! yes, this does help aubionotes quite a bit here too. this part (midi) of the code is likely to go away at some point, it would be best to use portmidi or something similar. The current baz tree can be browsed at: http://aubio.piem.org/archzoom/piem@altern.org--aubio-calabaza/aubio--mainline--0.3.1 And to obtain the last revision with baz: baz register-archive http://aubio.piem.org/bazaar/piem@altern.org--aubio-calabaza baz get piem@altern.org--aubio-calabaza/aubio--mainline I'm cc-ing aubio@piem.org. (the archive is now online at http://aubio.piem.org/archives/). greetings, Paul From jens.andreasen at chello.se Sat May 27 12:05:56 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat May 27 12:06:04 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware In-Reply-To: <20060527114943.6711.qmail@web52205.mail.yahoo.com> References: <20060527114943.6711.qmail@web52205.mail.yahoo.com> Message-ID: <1148745956.11015.0.camel@c80-216-124-251.cm-upc.chello.se> On Sat, 2006-05-27 at 04:49 -0700, Paul wrote: > Hi. > I rewrote the experimental time-stretching software > (discussed in linux-audio-user mailinglist in "How can > I time-stretch the sound like this" topic ) and I put > it > here: > http://hypermammut.sourceforge.net/src/paulstretch/ > > Please listen to audio examples here (with 20x > stretching): > http://hypermammut.sourceforge.net/src/paulstretch/example/ > > The algorithm is simple and it's described into the > readme.txt from the archive. There is room for > improovements to avoid over-smoothing (I wrote in > readme.txt how I think that is possible to do). > > Please tell me your opinion about it. Applause! :-D > > Paul > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com -- From paulgfx at yahoo.com Mon May 29 17:07:03 2006 From: paulgfx at yahoo.com (Paul) Date: Mon May 29 17:07:27 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware v.0.0.2 Message-ID: <20060529210703.33467.qmail@web52214.mail.yahoo.com> Hi. I released today the second version of the extreme-time-stretching software. It's here: http://hypermammut.sourceforge.net/src/paulstretch/ News: - Added a graphical user interface (requires wxWidgets). Now you can control the FFT size (buffer size) too. Also, you can use this program as a very interesting effect if you make FFT size large (even if the stretch parameter is close to 1) - Added Ogg Vorbis support for output (requires ogg vorbis libraries) - Added an "optimize" option to the FFT size to make it power of 2 or 3 for speedups (afaik the fftw library is optimised for these kinds of buffers). The disavantage is that the stretch value is now quantised (if you don't like this, you can disable the optimize checkbox). P.S. For now, there is no available resource checking (I mean if your disk is full or the buffer size is too large, the program will crash) Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From loki.davison at gmail.com Mon May 29 19:04:50 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon May 29 19:05:08 2006 Subject: [linux-audio-dev] Re: Midi Clock In-Reply-To: <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> Message-ID: On 5/27/06, Patrick Stinson wrote: > Take a look at OSC. It assumes that all computers' clocks are synced > via ntp, which is more than adequate to ensure its 64-bit fixed point > timestamps are accurate. This makes the programming easier and more > reliable, as you only have to program to your local clock. Relying on > an Ethernet LAN for heartbeat-style clock syncing is never a good > idea, as the MIDI specification describes (you don't see a Roland > keyboard assembling a TCP stack on its MIDI port, for example). > > OSC does not define a transport, so you may use TCP or UDP or whatever > you want, as many others do. I highly recommend this as a solution for > you. > also a osc sequencer would be useful and yet another loop based midi sequencer wouldn't be. I'd also recommend process seperation of gui and engine. Then you can write the engine in something like c and the gui in something like python. From x37v.alex at gmail.com Mon May 29 23:13:33 2006 From: x37v.alex at gmail.com (Alex) Date: Mon May 29 23:13:40 2006 Subject: [linux-audio-dev] precise event timer examples (HPET?) Message-ID: Does anyone have any examples that use HPET (or any other high resolution event) timers? I've built HPET support into my kernel but I cannot figure out how to compile the example given in the documentation : /usr/src/linux-2.6.12/Documentation/hpet.txt I have searched the web and I cannot quite figure out how people use these. I'd like to have micro-second precision and I'm wondering if there is a better way then polling the time of day? Thanks, Alex Norman From viceic at net2000.ch Tue May 30 02:09:03 2006 From: viceic at net2000.ch (Predrag Viceic) Date: Tue May 30 02:08:51 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware v.0.0.2 In-Reply-To: <20060529210703.33467.qmail@web52214.mail.yahoo.com> References: <20060529210703.33467.qmail@web52214.mail.yahoo.com> Message-ID: <200605300809.03989.viceic@net2000.ch> Hi Paul, How does your software compare to SoundTouch in regard to "less extreme" time stretching? many thanks, Predrag http://freecycle.redsteamrecords.com Le Lundi 29 Mai 2006 23:07, Paul a ?crit?: > Hi. > I released today the second version of the > extreme-time-stretching software. > It's here: > http://hypermammut.sourceforge.net/src/paulstretch/ > > News: > - Added a graphical user interface (requires > wxWidgets). Now you can control the FFT size (buffer > size) too. Also, you can use this program as a very > interesting effect if you make FFT size large (even if > the stretch parameter is close to 1) > - Added Ogg Vorbis support for output (requires ogg > vorbis libraries) > - Added an "optimize" option to the FFT size to make > it power of 2 or 3 for speedups (afaik the fftw > library is optimised for these kinds of buffers). The > disavantage is that the stretch value is now quantised > (if you don't like this, you can disable the optimize > checkbox). > > P.S. For now, there is no available resource checking > (I mean if your disk is full or the buffer size is too > large, the program will crash) > > Paul > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From jens.andreasen at chello.se Tue May 30 02:46:20 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue May 30 02:46:29 2006 Subject: [linux-audio-dev] Re: Midi Clock In-Reply-To: References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> Message-ID: <1148971580.10430.32.camel@c80-216-124-251.cm-upc.chello.se> On Tue, 2006-05-30 at 09:04 +1000, Loki Davison wrote: > On 5/27/06, Patrick Stinson wrote: > > Take a look at OSC. It assumes that all computers' clocks are synced > > via ntp, which is more than adequate to ensure its 64-bit fixed point > > timestamps are accurate. This makes the programming easier and more > > reliable, as you only have to program to your local clock. Relying on > > an Ethernet LAN for heartbeat-style clock syncing is never a good > > idea, as the MIDI specification describes (you don't see a Roland > > keyboard assembling a TCP stack on its MIDI port, for example). > > > > OSC does not define a transport, so you may use TCP or UDP or whatever > > you want, as many others do. I highly recommend this as a solution for > > you. > > > > also a osc sequencer would be useful and yet another loop based midi > sequencer wouldn't be. I'd also recommend process seperation of gui > and engine. Then you can write the engine in something like c and the > gui in something like python. Regarding gui/engine separation: This has occasionally been discussed before, with various suggestions of how to use pipes to make it work easily and consistently. I came to think of, why not use the alsa midi layer? The engine listens to a midi stream of commands which may be generated from a gui, or perhaps coming from an external controller/sequencer. The gui could listen to the same (external?) midi stream, showing you the current state if you need it. The advantage would be a consistent protocol for communicating between gui and engine. The gui could be a piece of harware that you happen to own. You could run headless and still have a full view of what is going on. Many devolopers, as well as musicians, can recite this protocol while they sleep, so no need to dig through source code to figure out how the implementation is supposed to work. Mmmm ... Perhaps one could even persuade the maintainers of Gtk/Glade to implement a midi-controller-field, automagically doing the house keeping and graphic updates? Rosegarden already have a build in midi-controller construction kit, which could be extended slightly to allow for buttons, sliders ... anything ... Or something similar in OSC. I am only advocating midi because, looking at the landscape, there seems to be some consensus on that protocol. -- mvh // Jens M Andreasen From paulgfx at yahoo.com Tue May 30 03:03:18 2006 From: paulgfx at yahoo.com (Paul) Date: Tue May 30 03:03:26 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware v.0.0.2 Message-ID: <20060530070318.65891.qmail@web52207.mail.yahoo.com> Hi. >Hi Paul, >How does your software compare to SoundTouch in regard >to "less extreme" time >stretching? This algorithm is made especially for extreme time stretching, for "less extreme" I recomand you to try other programs/algorithms :) Paul >many thanks, >Predrag >> Hi. >> I released today the second version of the >> extreme-time-stretching software. >> It's here: >> http://hypermammut.sourceforge.net/src/paulstretch/ > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From clemens at ladisch.de Tue May 30 03:23:58 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue May 30 03:25:46 2006 Subject: [linux-audio-dev] precise event timer examples (HPET?) In-Reply-To: References: Message-ID: <20060530072358.GB24519@turing.informatik.uni-halle.de> Alex wrote: > Does anyone have any examples that use HPET (or any other high > resolution event) timers? I've built HPET support into my kernel but > I cannot figure out how to compile the example given in the > documentation : > /usr/src/linux-2.6.12/Documentation/hpet.txt /dev/hpet didn't quite work in kernels before about 2.6.15 because of various bugs. The example program uses a kernel header that probably isn't available to user space programs. And if you got it to compile, it probably wouldn't run because the third timer is the only one available (the first two are used for the system timer and for RTC emulation, respectively), and most BIOSes don't initialize the third interrupt. > I'd like to have micro-second precision and I'm wondering if there is > a better way then polling the time of day? When HPET is enabled, gettimeofday() uses it. What is the output of "dmesg | grep -i hpet"? If you want to avoid the syscall overhead, you can try to call mmap() on /dev/hpet and read the timer directly. In that case, you don't need to use any header. HTH Clemens From patrickkidd.lists at gmail.com Tue May 30 03:29:13 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Tue May 30 03:29:21 2006 Subject: [linux-audio-dev] Re: Midi Clock In-Reply-To: References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> Message-ID: <664bf2b80605300029u4d70dc1lcdda10b531155292@mail.gmail.com> I wrote a client-side OSC sequencer for supercollider. check my site for "scsynth". On 5/29/06, Loki Davison wrote: > On 5/27/06, Patrick Stinson wrote: > > Take a look at OSC. It assumes that all computers' clocks are synced > > via ntp, which is more than adequate to ensure its 64-bit fixed point > > timestamps are accurate. This makes the programming easier and more > > reliable, as you only have to program to your local clock. Relying on > > an Ethernet LAN for heartbeat-style clock syncing is never a good > > idea, as the MIDI specification describes (you don't see a Roland > > keyboard assembling a TCP stack on its MIDI port, for example). > > > > OSC does not define a transport, so you may use TCP or UDP or whatever > > you want, as many others do. I highly recommend this as a solution for > > you. > > > > also a osc sequencer would be useful and yet another loop based midi > sequencer wouldn't be. I'd also recommend process seperation of gui > and engine. Then you can write the engine in something like c and the > gui in something like python. > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From _ at whats-your.name Tue May 30 03:41:38 2006 From: _ at whats-your.name (c) Date: Tue May 30 03:41:46 2006 Subject: [linux-audio-dev] Extreme time-stretching sofware v.0.0.2 In-Reply-To: <20060530070318.65891.qmail@web52207.mail.yahoo.com> References: <20060530070318.65891.qmail@web52207.mail.yahoo.com> Message-ID: <20060530074138.GB12901@replic.net> On Tue May 30, 2006 at 12:03:18AM -0700, Paul wrote: > Hi. > >Hi Paul, > > >How does your software compare to SoundTouch in > regard >to "less extreme" time > >stretching? > > This algorithm is made especially for extreme time > stretching, for "less extreme" I recomand you to try > other programs/algorithms :) > Paul cool. now i dont have to buy any more albums. my existing set is 3x as large. thanks!! > > >many thanks, > > >Predrag > > >> Hi. > >> I released today the second version of the > >> extreme-time-stretching software. > >> It's here: > >> http://hypermammut.sourceforge.net/src/paulstretch/ > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From paul at linuxaudiosystems.com Tue May 30 07:51:35 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue May 30 07:51:36 2006 Subject: [linux-audio-dev] precise event timer examples (HPET?) In-Reply-To: <20060530072358.GB24519@turing.informatik.uni-halle.de> References: <20060530072358.GB24519@turing.informatik.uni-halle.de> Message-ID: <1148989895.1711.43.camel@localhost.localdomain> On Tue, 2006-05-30 at 09:23 +0200, Clemens Ladisch wrote: > If you want to avoid the syscall overhead, you can try to call mmap() on > /dev/hpet and read the timer directly. In that case, you don't need to > use any header. and as a reminder, there is code within JACK now to do this, if you want an example. it was written by jussi laako. jackd can be told to use the HPET timer rather than gettimeofday or the cycle counter using the -"-clock hpet" command line argument. the code is in JACK SVN, publically accessible at: http://subversion.jackaudio.org/jack/trunk/jack --p "silly URL" From christie.tom at gmail.com Tue May 30 08:22:59 2006 From: christie.tom at gmail.com (tom christie) Date: Tue May 30 08:23:06 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1148662471.29421.2.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> Message-ID: <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> Looks good, I have one thought... One of the good things about moving to LV2 will be the possibility of extensions, possibly requiring new whizzy data types / classes on the ports. If this is the case is it a good idea to be tied down to the "enum SLV2DataType" which means the library has to know and support the data type (ie. be able to map "float" to SLV2_DATA_TYPE_FLOAT), and that new data types can only be added by changing the library. If the data type was presented just a char * to the string as given in the .ttl file, then the plugin authors would be free to work with new data types without having to get the core library changed. (This possibly holds for the enum SLV2PortClass too, although that's arguably less likely to need to change (?) ) I hope I've explained myself clearly enough! :) Any sense in this? On 5/26/06, Dave Robillard wrote: > On Fri, 2006-05-26 at 14:18 +0200, Lars Luthman wrote: > > On Thu, 2006-05-25 at 23:09 -0400, Dave Robillard wrote: > > > Hi all, > > > > > > I've been working on a host library for LV2 plugins. > > > > What's the license? GPL? > > Yes. > > -DR- > > From drobilla at connect.carleton.ca Tue May 30 11:43:57 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 30 11:44:51 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> Message-ID: <1149003837.8726.5.camel@DaveLap> On Tue, 2006-05-30 at 13:22 +0100, tom christie wrote: > Looks good, > > I have one thought... One of the good things about moving to LV2 > will be the possibility of extensions, possibly requiring new whizzy > data types / classes on the ports. > If this is the case is it a good idea to be tied down to the "enum > SLV2DataType" which means the library has to know and support the data > type (ie. be able to map "float" to SLV2_DATA_TYPE_FLOAT), and that > new data types can only be added by changing the library. If the data > type was presented just a char * to the string as given in the .ttl > file, then the plugin authors would be free to work with new data > types without having to get the core library changed. (This possibly > holds for the enum SLV2PortClass too, although that's arguably less > likely to need to change (?) ) > I hope I've explained myself clearly enough! :) > Any sense in this? This is why I added the UNKNOWN one; you will always be able to just get the property directly and check it's value. I suppose you're right, the enum doesn't really make the API that much cleaner. The problem with returning strings is namespace prefixes. It's all fine if the type is in the lv2: namespace so it can return something nice like lv2:float, but if it's something else it will have to return the fully qualified URI. For consistency's sake I'll have to return the full URI for everything. I think what I'll do is have the type function return a full URI, but #define symbols for the builtin port types (which is easily extensible without breaking anything). Something like: char* type = lv2_port_get_type(someplug, 0); if (!strcmp(type, LV2_DATATYPE_FLOAT)) /* ... */ free(type); Better? -DR- From christie.tom at gmail.com Tue May 30 12:53:45 2006 From: christie.tom at gmail.com (tom christie) Date: Tue May 30 12:53:56 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1149003837.8726.5.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> Message-ID: <958b3a2e0605300953y74033b2dkd231e36d32407f53@mail.gmail.com> Sounds reasonable to me. Just to clarify, does that mean LV2_DATATYPE_FLOAT would be #define'd as: "http://lv2plug.in/ontology#float" or something else?... I guess consistency would suggest using the same approach for both slv2_port_get_class() and slv2_port_get_data_type(). > The problem with returning strings is namespace prefixes. It's all fine > if the type is in the lv2: namespace so it can return something nice > like lv2:float, but if it's something else it will have to return the > fully qualified URI. For consistency's sake I'll have to return the > full URI for everything. > > I think what I'll do is have the type function return a full URI, but > #define symbols for the builtin port types (which is easily extensible > without breaking anything). > > Something like: > > char* type = lv2_port_get_type(someplug, 0); > if (!strcmp(type, LV2_DATATYPE_FLOAT)) > /* ... */ > free(type); > > Better? > > -DR- > > From S.W.Harris at ecs.soton.ac.uk Tue May 30 13:07:15 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue May 30 13:07:44 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1149003837.8726.5.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> Message-ID: <20060530170715.GF2609@login.ecs.soton.ac.uk> On Tue, May 30, 2006 at 11:43:57AM -0400, Dave Robillard wrote: > The problem with returning strings is namespace prefixes. It's all fine > if the type is in the lv2: namespace so it can return something nice > like lv2:float, but if it's something else it will have to return the > fully qualified URI. For consistency's sake I'll have to return the > full URI for everything. Returning QNames is bad mojo. > I think what I'll do is have the type function return a full URI, but > #define symbols for the builtin port types (which is easily extensible > without breaking anything). > > Something like: > > char* type = lv2_port_get_type(someplug, 0); > if (!strcmp(type, LV2_DATATYPE_FLOAT)) > /* ... */ > free(type); Makes sense to me. You could make the API (optionally?) take a char * to write the result into to avoid a lot of malloc() and free()s, but I doublt it's a worthwhile saving. - Steve From fons.adriaensen at skynet.be Tue May 30 13:38:37 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 30 13:30:25 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <20060530170715.GF2609@login.ecs.soton.ac.uk> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> Message-ID: <20060530173837.GA4862@linux-1> On Tue, May 30, 2006 at 06:07:15PM +0100, Steve Harris wrote: > On Tue, May 30, 2006 at 11:43:57AM -0400, Dave Robillard wrote: > > char* type = lv2_port_get_type(someplug, 0); > > if (!strcmp(type, LV2_DATATYPE_FLOAT)) > > /* ... */ > > free(type); > > Makes sense to me. You could make the API (optionally?) take a char * to > write the result into to avoid a lot of malloc() and free()s, but I doublt > it's a worthwhile saving. I'd consider any interface that just returns a constant and requires a malloc() and a free() to do it plain broken. This data doesn't live in kernel space, or does it ? You could just return a const char *. -- FA Follie! Follie! Delirio vano e' questo! From radarsat1 at gmail.com Tue May 30 13:47:51 2006 From: radarsat1 at gmail.com (Steve) Date: Tue May 30 13:47:59 2006 Subject: [linux-audio-dev] Re: Midi Clock In-Reply-To: <664bf2b80605300029u4d70dc1lcdda10b531155292@mail.gmail.com> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> <664bf2b80605300029u4d70dc1lcdda10b531155292@mail.gmail.com> Message-ID: <9b3e2dc20605301047m9e208e6nbcc74a96787550cd@mail.gmail.com> It is a good idea, as long as your interface is relatively simple... but what about when you want to do something that is sort of custom to your interface, like for example showing the waveform on the screen by sending peak or spectrum data. you'll end up having to create a mini "custom" protocol over MIDI using your own SysEx messages or something, so you may as well keep it simple and use pipes.. However, yes, for very simple interfaces, like a few knobs and sliders, it does make sense to use MIDI this way. You'd be building a "controller" for your realtime synth process, for example, which is exactly analagous to using an external controller for a hardware synth. Steve On 5/30/06, Patrick Stinson wrote: > I wrote a client-side OSC sequencer for supercollider. check my site > for "scsynth". > > On 5/29/06, Loki Davison wrote: > > On 5/27/06, Patrick Stinson wrote: > > > Take a look at OSC. It assumes that all computers' clocks are synced > > > via ntp, which is more than adequate to ensure its 64-bit fixed point > > > timestamps are accurate. This makes the programming easier and more > > > reliable, as you only have to program to your local clock. Relying on > > > an Ethernet LAN for heartbeat-style clock syncing is never a good > > > idea, as the MIDI specification describes (you don't see a Roland > > > keyboard assembling a TCP stack on its MIDI port, for example). > > > > > > OSC does not define a transport, so you may use TCP or UDP or whatever > > > you want, as many others do. I highly recommend this as a solution for > > > you. > > > > > > > also a osc sequencer would be useful and yet another loop based midi > > sequencer wouldn't be. I'd also recommend process seperation of gui > > and engine. Then you can write the engine in something like c and the > > gui in something like python. > > > > > -- > Patrick Kidd Stinson > http://www.patrickkidd.com/ > http://pkaudio.sourceforge.net/ > http://pksampler.sourceforge.net/ > From patrickkidd.lists at gmail.com Tue May 30 14:41:17 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Tue May 30 14:41:24 2006 Subject: [linux-audio-dev] Re: Midi Clock In-Reply-To: <9b3e2dc20605301047m9e208e6nbcc74a96787550cd@mail.gmail.com> References: <20060526113153.f74e5b1e.krampenschiesser@freenet.de> <1148649539.9544.145.camel@c80-216-124-251.cm-upc.chello.se> <20060526164649.377c7259.krampenschiesser@freenet.de> <9b3e2dc20605261400s3744959l416122e56c42013b@mail.gmail.com> <20060527013111.754a7b83.krampenschiesser@freenet.de> <664bf2b80605261859t6cad4844q6037aa97249397c2@mail.gmail.com> <664bf2b80605300029u4d70dc1lcdda10b531155292@mail.gmail.com> <9b3e2dc20605301047m9e208e6nbcc74a96787550cd@mail.gmail.com> Message-ID: <664bf2b80605301141w6d9bd6dex78ba2c8e296c43cb@mail.gmail.com> bingo. I kicked off a very similar thread with Paul Davis earlier in April... On 5/30/06, Steve wrote: > It is a good idea, as long as your interface is relatively simple... > but what about when you want to do something that is sort of custom to > your interface, like for example showing the waveform on the screen by > sending peak or spectrum data. > > you'll end up having to create a mini "custom" protocol over MIDI > using your own SysEx messages or something, so you may as well keep it > simple and use pipes.. > > However, yes, for very simple interfaces, like a few knobs and > sliders, it does make sense to use MIDI this way. You'd be building a > "controller" for your realtime synth process, for example, which is > exactly analagous to using an external controller for a hardware > synth. > > Steve > > > On 5/30/06, Patrick Stinson wrote: > > I wrote a client-side OSC sequencer for supercollider. check my site > > for "scsynth". > > > > On 5/29/06, Loki Davison wrote: > > > On 5/27/06, Patrick Stinson wrote: > > > > Take a look at OSC. It assumes that all computers' clocks are synced > > > > via ntp, which is more than adequate to ensure its 64-bit fixed point > > > > timestamps are accurate. This makes the programming easier and more > > > > reliable, as you only have to program to your local clock. Relying on > > > > an Ethernet LAN for heartbeat-style clock syncing is never a good > > > > idea, as the MIDI specification describes (you don't see a Roland > > > > keyboard assembling a TCP stack on its MIDI port, for example). > > > > > > > > OSC does not define a transport, so you may use TCP or UDP or whatever > > > > you want, as many others do. I highly recommend this as a solution for > > > > you. > > > > > > > > > > also a osc sequencer would be useful and yet another loop based midi > > > sequencer wouldn't be. I'd also recommend process seperation of gui > > > and engine. Then you can write the engine in something like c and the > > > gui in something like python. > > > > > > > > > -- > > Patrick Kidd Stinson > > http://www.patrickkidd.com/ > > http://pkaudio.sourceforge.net/ > > http://pksampler.sourceforge.net/ > > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From drobilla at connect.carleton.ca Tue May 30 15:09:33 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 30 15:10:24 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <958b3a2e0605300953y74033b2dkd231e36d32407f53@mail.gmail.com> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <958b3a2e0605300953y74033b2dkd231e36d32407f53@mail.gmail.com> Message-ID: <1149016174.12003.2.camel@DaveLap> On Tue, 2006-05-30 at 17:53 +0100, tom christie wrote: > Sounds reasonable to me. > > Just to clarify, does that mean LV2_DATATYPE_FLOAT > would be #define'd as: "http://lv2plug.in/ontology#float" > or something else?... Yep. > I guess consistency would suggest using the same approach for both > slv2_port_get_class() and slv2_port_get_data_type(). Yeah, true. I'll give everything a look through and make sure it will make sense to do so in all cases (without mucking up the API too much). I'm a bit unhappy that it makes code longer and more messy though. The primary design goal here is to make host code as terse and simple as possible. strcmp'ing a string and then freeing it is quite a bit uglier than just testing an enum val :/ -DR- From drobilla at connect.carleton.ca Tue May 30 15:10:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 30 15:11:44 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <20060530173837.GA4862@linux-1> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> <20060530173837.GA4862@linux-1> Message-ID: <1149016238.12003.4.camel@DaveLap> On Tue, 2006-05-30 at 19:38 +0200, fons adriaensen wrote: > On Tue, May 30, 2006 at 06:07:15PM +0100, Steve Harris wrote: > > On Tue, May 30, 2006 at 11:43:57AM -0400, Dave Robillard wrote: > > > > char* type = lv2_port_get_type(someplug, 0); > > > if (!strcmp(type, LV2_DATATYPE_FLOAT)) > > > /* ... */ > > > free(type); > > > > Makes sense to me. You could make the API (optionally?) take a char * to > > write the result into to avoid a lot of malloc() and free()s, but I doublt > > it's a worthwhile saving. > > I'd consider any interface that just returns a constant and requires > a malloc() and a free() to do it plain broken. This data doesn't live > in kernel space, or does it ? You could just return a const char *. It's not a constant. -DR- From fons.adriaensen at skynet.be Tue May 30 16:27:02 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 30 16:19:10 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1149016238.12003.4.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> <20060530173837.GA4862@linux-1> <1149016238.12003.4.camel@DaveLap> Message-ID: <20060530202702.GB4862@linux-1> On Tue, May 30, 2006 at 03:10:38PM -0400, Dave Robillard wrote: > > I'd consider any interface that just returns a constant and requires > > a malloc() and a free() to do it plain broken. This data doesn't live > > in kernel space, or does it ? You could just return a const char *. > > It's not a constant. Oh, I didn't know know port types could change dynamically. -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Tue May 30 17:48:35 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 30 17:49:27 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <20060530202702.GB4862@linux-1> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> <20060530173837.GA4862@linux-1> <1149016238.12003.4.camel@DaveLap> <20060530202702.GB4862@linux-1> Message-ID: <1149025716.14516.8.camel@DaveLap> On Tue, 2006-05-30 at 22:27 +0200, fons adriaensen wrote: > On Tue, May 30, 2006 at 03:10:38PM -0400, Dave Robillard wrote: > > > > I'd consider any interface that just returns a constant and requires > > > a malloc() and a free() to do it plain broken. This data doesn't live > > > in kernel space, or does it ? You could just return a const char *. > > > > It's not a constant. > > Oh, I didn't know know port types could change dynamically. Well, they can't, but the actual port type values in the data file aren't fixed in any way - there can be any URI (string) there. The function we're talking about pulls this info directly from the data file (not eg from a loaded Port object which would have a const type string). The library doesn't load all the stuff from the file into memory (in which case the port type would be const), it just queries the data file every time you ask for something (I won't attempt to enforce my guess about what a host would want to cache in memory, that's the hosts' decision). (Rationale being that an LV2 host can run an LV2 plugin keeping only the actual DLL in memory (eg consuming far less memory than an equivalent LADSPA plug), rather than having a bunch of data sitting around that may not be useful) -DR- From fons.adriaensen at skynet.be Tue May 30 18:24:06 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue May 30 18:16:42 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1149025716.14516.8.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> <20060530173837.GA4862@linux-1> <1149016238.12003.4.camel@DaveLap> <20060530202702.GB4862@linux-1> <1149025716.14516.8.camel@DaveLap> Message-ID: <20060530222406.GC4862@linux-1> On Tue, May 30, 2006 at 05:48:35PM -0400, Dave Robillard wrote: > The function we're talking about pulls this info directly from the data > file (not eg from a loaded Port object which would have a const type > string). The library doesn't load all the stuff from the file into > memory (in which case the port type would be const), it just queries the > data file every time you ask for something (I won't attempt to enforce > my guess about what a host would want to cache in memory, that's the > hosts' decision). In that case it would even make more sense to have the allocation for this string done by the caller. > (Rationale being that an LV2 host can run an LV2 plugin keeping only the > actual DLL in memory (eg consuming far less memory than an equivalent > LADSPA plug), rather than having a bunch of data sitting around that may > not be useful) The amount of data required for this in LADSPA is really trivial, unless it's all created dynamically as is done in some plugins (never understood the purpose of allocating a and then copying a constant into it - the thing already exists). Also considering the amount of code required to get at the data, and that you could encode up to 256 port types into a byte, inside the .so, I wonder if there is any real gain. I can understand that a host would not like to have all plugins loaded all the time just for the purpose of e.g. presenting a list to the user, but there are less convoluted solutions to that problem. -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Tue May 30 22:54:27 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue May 30 22:55:21 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <20060530222406.GC4862@linux-1> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <20060530170715.GF2609@login.ecs.soton.ac.uk> <20060530173837.GA4862@linux-1> <1149016238.12003.4.camel@DaveLap> <20060530202702.GB4862@linux-1> <1149025716.14516.8.camel@DaveLap> <20060530222406.GC4862@linux-1> Message-ID: <1149044067.17482.48.camel@DaveLap> On Wed, 2006-05-31 at 00:24 +0200, fons adriaensen wrote: > On Tue, May 30, 2006 at 05:48:35PM -0400, Dave Robillard wrote: > > > The function we're talking about pulls this info directly from the data > > file (not eg from a loaded Port object which would have a const type > > string). The library doesn't load all the stuff from the file into > > memory (in which case the port type would be const), it just queries the > > data file every time you ask for something (I won't attempt to enforce > > my guess about what a host would want to cache in memory, that's the > > hosts' decision). > > In that case it would even make more sense to have the allocation > for this string done by the caller. That makes the code even more convoluted, and the caller has no idea beforehand how big the string might be. Many functions in this library return strings, I'm not very keen on the idea of making them all take a writeable buffer and a size as a parameter (it's weird, more prone to breakage, and requires more code on the host's part). I could be missing something though - what's the benefit? > > (Rationale being that an LV2 host can run an LV2 plugin keeping only the > > actual DLL in memory (eg consuming far less memory than an equivalent > > LADSPA plug), rather than having a bunch of data sitting around that may > > not be useful) > > The amount of data required for this in LADSPA is really trivial, > unless it's all created dynamically as is done in some plugins > (never understood the purpose of allocating a and then > copying a constant into it - the thing already exists). > > Also considering the amount of code required to get at the data, > and that you could encode up to 256 port types into a byte, inside > the .so, I wonder if there is any real gain. 640k ought to be enough for anybody. :) Who gets to designate what values correspond to what type? What if something messes up and different people start using type 38 for different types of data? Crash. (This is the lesson learned with LADSPA numeric ID's - it doesn't work). As for 'the amount of code', from the host perspective it's much, much less with libslv2 than with LADSPA. I won't lie - accessing the data for LV2 plugins directly /is/ a lot more difficult than LADSPA, and involves things the vast majority of LAD coders probably don't care to spend time learning about - that's why I wrote the library (to make that a non-issue). I think maybe the point of all this RDF stuff has been missed on this list in general (stop reading here if you don't care): The amount of data associated with a plugin may not be 'trivial' at all - an LV2 plugin could have HUGE amounts of data associated with it if someone takes the time to put it there (heck, considering you can point to web resources and the like it wouldn't be difficult to make a plugin which no known computer could store /all/ information about in RAM, let alone one a LADer would own). Authors can put absolutely anything in there if they want - ridiculous things, host specific things, categorization based on how much they personally like the thing, /anything/. The magic of RDF is that there is no downside whatsoever to doing this. You just can't break anything by adding more data. Maybe noone cares that you think a plugin sounds "swooshy", but go right ahead and stick that information in there if you want. None of this requires changes to the core LV2 spec (or any centralised consensus whatsoever). It's best illustrated by (a less ridiculous) example - take the oft requested "port grouping" feature (eg signifying that two or more ports are part of the same group, like a stereo channel): LADSPA: Start mailing list discussion, beat the topic to death over weeks, realize it breaks the spec and it's not worth breaking compatibility over, have a nice discussion about how the spec sucks because your pet feature isn't in there, someone mention something about GMPI saving the day (hah), someone else decides to take the opportunity to talk about plugin GUIs for the 99999th time, etc. etc. etc, accomplish nothing. LV2: Add the data to the data file. There is no step 2. Convoluted? You tell me. -DR- From lars.luthman at gmail.com Wed May 31 10:12:49 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed May 31 10:13:05 2006 Subject: [linux-audio-dev] Abandoned Csound tracker looking for maintainer Message-ID: <1149084769.7969.5.camel@localhost> A couple of years ago I started writing a tracker-like GUI program to control Csound, but then I mostly lost interest in Csound and forgot about it. It's a bit like Buzz or Psycle or Octal in that it has a built-in "modular synth" where you connect Csound instruments and a traditional tracker-style pattern editor. It probably doesn't work with recent Csound versions and probably doesn't even build with recent compilers and libraries, and I'm not going to hack any more on it. But if anyone is interested in taking over, the source and other things can be found here: http://keso-project.sourceforge.net/ I'd be happy to hand over the SF project if anyone is interested. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060531/4910c5c9/attachment-0001.bin