Re: [ecasound] Plea for a new controller

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Tue Apr 07 2009 - 01:36:19 EEST


On Fri, 3 Apr 2009, Dominic Sacré wrote:

[return values with OSC]
> convenient shortcut in many cases. It's not part of the OSC spec
> though (it depends on the transport protocol being used), so a way to
> explicitly specify an address would still be required.
> The bigger problem with return values is the fact that OSC messages
> are always transmitted asynchronously, so there's no (easy) way for a
> client to wait until a command has completed. There are ways to work

thanks for these comments! I'm even more convinced now that the OSC
interface should not be modelled after ECI -- neither in style nor in the
terms of functionality (=complexity).

Instead, OSC interface should offer simple interface:
   - transport control (start, stop, seek, live-seek)
   - parameter control
   - a small set of toggles (e.g. per-chain mute and bypass)
   -> i.e. roughly what can be done with MIDI, but with the benefits
      of OSC (e.g. possibility to pass parameter as floats)

I think we can safely ignore the whole concept of "chainsetup" in the OSC
interface and instead implicitly operate on the connected objects (the
"connected chainsetup" in ecasound lingo). This already simplifies the
interface a great deal. So you'd have:

  - /ecasound/transport run
  - /ecasound/transport stop
  - /ecasound/position 0.4
  - /ecasound/chain/myrec/bypass True
  - /ecasound/chain/myrec/op/2/param/3 4.5
  - /ecasound/chain/myrec/op/2/param/cutoff 440.0
  - .. and so forth..

... another simplification is not to implement any return values
(the interface would only allow one-way messaging).

This email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!

Ecasound-list mailing list
Received on Tue Apr 7 04:15:01 2009

This archive was generated by hypermail 2.1.8 : Tue Apr 07 2009 - 04:15:01 EEST