Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 4, Issue 61

by Bill Schottstaedt

> 440.0 is still an exact integer Hunh? What Scheme is this? The Scheme spec says "It [a numerical constant] is inexact if it contains a decimal point..." It also says "inexactness is a contagious property of a number". In any case, type checks are trivial.

21 years, 4 months

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

by Kjetil Svalastog Matheussen

rd(a)alphalink.com.au: > > For what scheme implementation are you using? And where can I > > get what you are using? > > I use Matthew Flatt's mzscheme, which is part of the PLT project, see > <www.plt-scheme.org>. I run it with a two line patch to put the Boehm > GC into incremental mode. > > There is a pre-release archive at <www.alphalink.com.au/~rd>. I have Thanks, I'm looking at it now. I was hoping you would have used guile instead so that I could use it in pure data, so I was a bit dissapointed. > used this and James McCartney's SC3 synthesis server, see > <supercollider.sf.net>, as my work environment for over a year and it is > stable, however unless there is a particular affinity for Lisp I would > recommend using James McCartney's Smalltalk dialect as a language > client. > Actually, I'm currently using python and pure data to access the SC3 synth engine. Look at the supercollider module in the pure-data cvs repository. But it would be nice to use scheme as well as python. --

21 years, 4 months

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

by rd＠alphalink.com.au

I am afraid have gotten to your OSC messages a bit late, I can only read lists at web archives at present and the jack lists have been down... > * No service discovery. This is a big deal, but can be solved /if/ we I don't know of a database, which I guess is not a good situation. CNMAT might be interested in doing the basic administration required for a port register. I think that a database of static port numbers is preferable to a dynamic system *if* it is workable. If a dynamic system were neccessary it should be implemented as an OSC server! I am actually not exactly sure what you mean by service discovery? > I'm very happy to discussus a GPL'd library implementation or I have had to do some work on the OSC implementation I have been using in order to address two issues. I think you will need to address these with liblo also. They are: 1. type coercion and 2. variable argmument messages. I am going to attach the note I wrote about the implementation below, which describes these in detail, but briefly on type coercion: Given the message shape ("/foo/bar" "fi") as in the testlo.c file, a receiver should match not only ("/foo/bar" "fi" 2.0 23) but also ("/foo/bar" "ii" 2 23) and ("/foo/bar" "if" 2 23.0) and in fact all other possible numerical encodings, and provide them to the handler in the form requested. The work I have done *only* provides the byte string decoder and encoder, but it does support all the extended basic OSC types and numerical and string coercion. I think you could use it as is if you wanted, or of course just take whatever you need. I will happily implement/apply any changes/fixes required to make it usable for you. The implementation is in the file 'osc.c' in the jack.clock or jack.scope archives at <http://www.alphalink.com.au/~rd>. It works for me but is otherwise untested! Apart from the above the design looks good, although personally I agree with James McCartney, see SC3 or recent post to OSC_dev, that combining the verb and the subject in the address is a bad idea, and would prefer to see a library that discourages that use ;) (This would also make the handler type declarations simpler...) Regards, Rohan

21 years, 4 months

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

by rd＠alphalink.com.au

> Sending '10.1' to a slot that is semantically an integer should > be undefined, though in practice you get '10'. Sorry, not even I agree with that. I meant to say that the floor/truncate/round/ceiling decision should be unspecified.

21 years, 4 months

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

by Juhana Sadeharju

>From: torbenh(a)gmx.de > [ gnomecanvas ] >the only problem would be determining widget size when you add a widget >to the canvas. gtk behaves sort of strange there. [ Posted this to gtk-app-devel-list as well. Reply to where you wish as I will summary. ] Should the module widgets be put to a fixed size container before they are inserted to the canvas? Or what is the problem? I tested with Glade: created a top window with one "Fixed Position" container widget, added viewport to the "Fixed Position", inserted vbox to viewport, inserted horizontal scales to each slot of the vbox. Then I took the properties of the viewport and changed viewport's position and size. Only problem appeared when the viewport size was made smaller than the minimum size of all scales. Viewport could be made very small in which case the scales were clipped agains the viewport. Is there any way to determine when the viewport becomes smaller than the vbox holding the scales? (Or the vbox larger than the viewport.) Does the viewport generate any signals in these cases? Is the viewport a wrong widget for the task? Is there any other constant size container in GTK? Regards, Juhana

21 years, 4 months

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

by rd＠alphalink.com.au

> OK, I've thought about this some more and I think I agree with > you now. I'l add type coercion when I have time, should be easy > enough. I think a widely used library that does this transparently will make life better for everyone. I hope the implementation I mentioned earlier can save you some time :) > typed APIs. In this case, if we only do conversions between different > numerical types I dont see that it will hurt, as long as the corner cases > are handled sensibly. I don't think you need to worry about this, if the coercion changes the semantic value, not just the representation or the precision, the sender is in error. Sending '10.1' to a slot that is semantically an integer should be undefined, though in practice you get '10'. Receivers need to run domain checks in any case... Regards, Rohan

21 years, 4 months

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

by rd＠alphalink.com.au

> an integer in scheme? Couldnt the problem be solved by specifying > the type explicitly at send time and doing the coercion then? eg: > > (-> "/foo" "isf" 100 "hello" 100.0) That is exactly what would be required and it is not at all good. People in user space should not have to even know that there are single and double precision floating point representations in order to set the frequency of an instrument. Especially not from a language environment where the distinction does not even exist! And it will afflict not only Lisps and dialects but SmallTalks and dialects and MLs and dialects and so on. I don't know the Patcher dialects but I imagine things would be as bad if not worse. It loses straight up for variable arity messages, (apply -> "/n_setn" node 0 data-from-somewhere). And even from C like languages users still need to *remember* for every OSC message they ever want to send whether '/frequency' is required as a single or double precision real number, and whether '/midi-note' is required as a 'c' integer, an 'i' integer, an 'f' float, or a 'd' double, all of which are reasonable requirements for different implemntations. It means that if two synths have a '/global-gain' controller you might need to format two different OSC packets to tell them to be quiet [one with a 'f' zero and one with a 'd' zero]. It means that if a synth implementor decides that the '/phase' input really should be double precision she cannot change the request type from the library because it will break *every existing user* of her synth! Their single precision phase values are no longer good enough? Surely at this point the implementor will probably just fix the library to do type coercion or find another library... In the redundant case the coercion adds one integer comparison to the dispatch path per argument, and thoughtful ordering of the coercion table should get most common cases in two or three comparisons; it is not an expensive operation. And I am still arguing that it is an important aspect of OSC that when a synth advertises a '/freq' message, users can be confident that sending it 440, whether encoded as a 32bit or 64bit integer, or as a 32bit or 64bit float, will likely tune the synth to A440. OSC is in user space, I think it would be a pity if synths advertised '/freqi', '/freqh', '/freqf' and '/freqd' messages in an attempt to help users out. Regards, Rohan

21 years, 4 months

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

by rd＠alphalink.com.au

> For what scheme implementation are you using? And where can I > get what you are using? I use Matthew Flatt's mzscheme, which is part of the PLT project, see <www.plt-scheme.org>. I run it with a two line patch to put the Boehm GC into incremental mode. There is a pre-release archive at <www.alphalink.com.au/~rd>. I have used this and James McCartney's SC3 synthesis server, see <supercollider.sf.net>, as my work environment for over a year and it is stable, however unless there is a particular affinity for Lisp I would recommend using James McCartney's Smalltalk dialect as a language client. Regards, Rohan

21 years, 4 months

[linux-audio-dev] OSC, service discovery ...

by John Lazzaro

Hi everyone, Just wanted to put in a plug for IETF-based solutions to doing service discovery for OSC -- basically, this would entail using SIP: http://www.ietf.org/rfc/rfc3261.txt for session management, and SDP: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-15.txt to describe the sessions themselves. To specify OSC in SDP, you'd use UDP or TCP as a transport specifier on the media line, and make up (and eventually, register) a "fmt" parameter for OSC. One of the things I'm planning to do now that RTP MIDI is finally nearing Last Call is to look at session management frameworks for RTP MIDI that would use SIP + SDP. If OSC went this route too, applications could use the Offer/Answer protocol: http://www.ietf.org/rfc/rfc3264.txt to negotiate to use MIDI (for baseline support) or OSC (to do more sophisticated things). This was one of the motivations behind RTP MIDI -- to offer a migration path from MIDI, without requiring backward-compatibility between control languages ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

21 years, 4 months

[linux-audio-dev] [ANN] liblrdf 0.3.4

by Steve Harris

liblrdf is a lightweight RDF metadata handling library with extensions for manipulating LADSPA Schema-specific data. http://plugin.org.uk/lrdf/ This version adds: * MacOSX compatibility, courtesy of Taybin Rutkin * A convienient method for reading control scale points * A convienient method for writing preset information An example showing how to use the two new methods can be found in examples/scale_test.c and examples/setting_test.c Scales are a way of mapping the semantics of port values to labels, eg. that an oscilator wave control has known behaviours for 0, 1 and 2 mapping to "sine", "square" and "saw". An RDF scale description of his plugins is included with Tom's Audio Plugins (http://www.hszk.bme.hu/~st444/tap/tap.html) and an RDF description of the scales for mine is on the website (http://plugin.org.uk/src/metadata/swh-scales.rdf, you can install it in /usr/local/(share/)ladspa/rdf/) and will be included in the next release. - Steve

21 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev