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.
--
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
> 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.
>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
> 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
> 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
> 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
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
---
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
>From: "Doug Wellington" <ddw(a)dakotacom.net>
>
>Previously:
>>> Reminds me of that old saying, "Linux is only free if your time
>>> isn't worth anything"...
>>
>> True, sort of, but you have to remember that "there's no such thing
>> as a free lunch."
>
>TANSTAAFL - exactly! There's always a price. Either you do it
>yourself, or you have someone else do it. Time vs. money...
Or, either you do it in N months or someone else do it in a week.
The sentence "you have someone else do it" does not sound very
realistic: 8 years ago I suggested first time a simple rectangular
re-adjustable selection tool to GIMP. Once again I suggested it
a few weeks ago and the task was again "assigned" to me even I asked
a coder with who together I could have implemented the thing. Now
GIMP does not compile in my Linux which means automatic delay of
several months (more likely a year) before I have a change to get
new Linux distribution. The tool would be highly needed as GIMP does
not have a re-adjustable rectangular selection tool (it's currently
only "if it went wrong, start from beginning"). Like having audio
editor without re-adjustable selection tool.
I simply don't understand why capable GIMP developers cannot implement
the simple feature. There is no sense in that I should learn GIMP
internals -- I could use that time for developing my own projects
instead of wasting the time to sidetracks.
Regards,
Juhana
