My presentation + error in the OSC documentation

[Aurélien Roux-2]

Hi there,

I'm new to this list, quite new to eacsound (though I already used it to
record live shows, and used ecasignalview to monitor some things several
years ago), but not quite new to Linux Audio things.

I'm working in an Freak and Free Arts Coo[r]p called AMMD
(www.ammd.net), which are artists caring about artists (production,
management, booking, ads...), with a very high ethical sense of all this
these words, and the whole thing being sustained by the use of Free Art
License only, and Free Softwares also (thought some artists coming by us
use several proprietary things when they arrive).

My job in here consists in:
- first, being a musician/actor, especially in the band Sebkha-Chott
(www.sebkhachott.net), and also in several other projects,
- second, manage the whole AMMD, and lead and book most of the projects,
being only the administrative starter on this,
- third, I'm sound technician in the AMMD, which owns a studio (see
www.linuxmao.org for details, or check www.ammd.net),
- fourth, teach the use of free softwares for live shows and audio/video
production ; on this part I teach future sound guys, as well as already
sound guys, as well as musician, music teacher, or even teenage
beginning music. Our aim is to make it possible for each and everyone,
and by working for already skilled people (who have funds raising for
their continuous learning), we might teach for teenage people (who have
nothing),
- fifth, I do help theater companies, bands, and so on, to adapt their
setup with free softwares, sometimes developping part of a software for
them. Though, I'm not a skilled applicative progammer at all, and
generally, my patches, though working in the very special case I've
written them for, are refused by the apps developpers!!! ;)

Well, that's it.


So, I'm going to use ecasound in a quite big project, including synths,
rhythmbox, audio routing and mixing, monitors management, and so on.
I want to control it with OSC (as all other softwares I use are using
it), and I found an error in the OSC documentation ; it's written that
the standard path for an op is:

/ecasound/chain/NAME/op/OPID/param/ID

but this doesn't work, I finally found it is:

/ecasound/chain/CHAINID/op/OPID/param/ID

Actually, as I've thought this part is being developped right now, I
would suggest the following:

/ecasound/chain/CHAINNAME/op/OPNAME/param/PARAMNAME

because it's much easier for "non-informatic" people, and much more
readable when you monitor your OSC messages by the way.


See you.
Aurélien

--
Aurélien - Chargé de productions Musiques
AMMD (Freak and Free Arts Coo[r]p)
[Booking - Productions - Promotion - Studio & Formations]
Mairie de Connerré - Rue de l'Abreuvoir - 72160 Connerré
[phone] (Mardi-Jeudi-Vendredi / 9h-17h)
www.ammd.net

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Aurélien Roux-2]

Le 07/02/2012 11:34, ORL a écrit :

> Hi there,
>
> I'm new to this list, quite new to eacsound (though I already used it to
> record live shows, and used ecasignalview to monitor some things several
> years ago), but not quite new to Linux Audio things.
>
> I'm working in an Freak and Free Arts Coo[r]p called AMMD
> (www.ammd.net), which are artists caring about artists (production,
> management, booking, ads...), with a very high ethical sense of all this
> these words, and the whole thing being sustained by the use of Free Art
> License only, and Free Softwares also (thought some artists coming by us
> use several proprietary things when they arrive).
>
> My job in here consists in:
> - first, being a musician/actor, especially in the band Sebkha-Chott
> (www.sebkhachott.net), and also in several other projects,
> - second, manage the whole AMMD, and lead and book most of the projects,
> being only the administrative starter on this,
> - third, I'm sound technician in the AMMD, which owns a studio (see
> www.linuxmao.org for details, or check www.ammd.net),
> - fourth, teach the use of free softwares for live shows and audio/video
> production ; on this part I teach future sound guys, as well as already
> sound guys, as well as musician, music teacher, or even teenage
> beginning music. Our aim is to make it possible for each and everyone,
> and by working for already skilled people (who have funds raising for
> their continuous learning), we might teach for teenage people (who have
> nothing),
> - fifth, I do help theater companies, bands, and so on, to adapt their
> setup with free softwares, sometimes developping part of a software for
> them. Though, I'm not a skilled applicative progammer at all, and
> generally, my patches, though working in the very special case I've
> written them for, are refused by the apps developpers!!! ;)
>
> Well, that's it.
>
>
> So, I'm going to use ecasound in a quite big project, including synths,
> rhythmbox, audio routing and mixing, monitors management, and so on.
> I want to control it with OSC (as all other softwares I use are using
> it), and I found an error in the OSC documentation ; it's written that
> the standard path for an op is:
>
> /ecasound/chain/NAME/op/OPID/param/ID
>
> but this doesn't work, I finally found it is:
>
> /ecasound/chain/CHAINID/op/OPID/param/ID
>
> Actually, as I've thought this part is being developped right now, I
> would suggest the following:
>
> /ecasound/chain/CHAINNAME/op/OPNAME/param/PARAMNAME
>
> because it's much easier for "non-informatic" people, and much more
> readable when you monitor your OSC messages by the way.
>
>
> See you.
> Aurélien
>

Ahem, auto-reply, just to announce I didn't had understood that -a:
could be followed by a string, and that this string was called
"chainname". So it's working perfectly, and there's no error in the doc.

I've checked the code a bit, but didn't find any easy way to get op
giving their name to the OSC path, directly. It's annoying, as if you,
for example, choose to use another op before the others, all your OSC
controls upon that chain will be false.... In my particular case, it
obliged me to make 2 chains for each "strip", the second beginning with
-eadb, so that I'm sure I will act on the attenuation by sending an osc
message at the 1st op.


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

btw, welcome to the list!

On Tue, 7 Feb 2012, ORL wrote:

>> /ecasound/chain/NAME/op/OPID/param/ID
[...]
>> /ecasound/chain/CHAINID/op/OPID/param/ID
>
> Ahem, auto-reply, just to announce I didn't had understood that -a:
> could be followed by a string, and that this string was called
> "chainname". So it's working perfectly, and there's no error in the  doc.

Yup, that's correct. But it's indeed a bit confusing as all the examples
and docs (a habit of mine that dates to earliest versions) use numerical
chain names, while in practise they could be anything.

> I've checked the code a bit, but didn't find any easy way to get op
> giving their name to the OSC path, directly. It's annoying, as if you,
> for example, choose to use another op before the others, all your OSC
> controls upon that chain will be false.... In my particular case, it
> obliged me to make 2 chains for each "strip", the second beginning with
> -eadb, so that I'm sure I will act on the attenuation by sending an osc
> message at the 1st op.

This is a valid problem, but there's no easy way to fix this with the
current API (both ECI and OSC). The root of the problem is that chain op
instances do not have unique names. If you'd have two amplify-ops (-eadb)
in the same chain, there's no way to separate the two (both instances have
the same name and description). And as ordering matters (one must be able
to address the first, second and Nth amplify in a chain), this would need
a new abstraction (assigning/exposing a unique string to all op
instances).

As a practical workaround (in ECI apps), you can use introspection to
track chainops. E.g. "cop-iselect 1 ; cop-describe" tells you what is the
current first chainop in the chain. If this is shown in the UI, one will
never accidentally control the wrong chain op.

But hmm, I can now see the problem with OSC apps, as there's no
'cop-describe' equivalent in the OSC interface at the moment.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list