[Ardour-Dev] OSC next
melaniebernkopf at gmail.com
Fri May 13 09:13:54 PDT 2016
yes I can only give a full ack to this it is just mimic of the position and
not about gain or DB.
Through my research about controllers for osc i found that there is mainly
software like touch osc used real hardware controllers are still very rare.
Maybe because Micro controllers have a hard time with floats and hardware
producers actually don´t use something different than what is for example
used on the Arduino.
So it is mainly on one side Micro controllers that give people the feel of
working with a Mixing console having trouble with floats and on the other
side we have software that can handle floats without problems.
Actually i just downloaded the TouchOSC editor and had a look at it you are
free to edit the range of faders and it is actually possible to enter
0-1023 or whatever. 0 to 1 is just when you set auto on the Fader (which is
default). PD extended if meant also has the possibility to adjust the
slider in the range wanted with the possibility to route incoming messages
into the fader.
VUmeter is something different that really uses gainDB but if I get it
right it is not about Meterbridges right now so let us leave that out now.
Other OSC apps/programs not tested by myself.
As said before int1024 seems to be the most versatile.
By the way all 12 Faders are running smoothly with the latest osc branch
after the code rework on my Micro controller very nice work.
2016-05-13 11:26 GMT+02:00 Jörn Nettingsmeier <nettings at stackingdwarves.net>
> On 05/13/2016 12:38 AM, Len Ovens wrote:
>> Quick question for those interested.
>> Right now I have 4 different kinds of fader control (route gain):
>> absolute gain,
>> gain in dB,
>> fader position and
>> fader position as an uint.
>> Right now these are all separate commands:
>> If the GUI fader is changed, the same message is sent back to the
>> control surface with the new value as well so that motor faders,
>> encoders or remote GUIs can track GUI changes. However, the surface
>> needs to know fader (and other) positions before the user tries to
>> change the control or Ardours value will jump to where the surface's
>> fader is. So there is a new /set_surface command that sets some
>> variables for each surface in use. If that surface has feedback turned
>> on, the current values will be sent to the surface. One of the values
>> sent with the /set_surface command is the fader math to use. As such
>> ardour already knows what math to use and could be just using
>> /strip/gain for all four of the above. The only advantage for keeping
>> all of the commands is for backwards compatability.
>> So my question is: should I keep all four messages intact or just use
>> the one /strip/gain? (this would also impact /master/gain and
>> /monitor/gain which I am working on now)
> can't comment on whether to retain all, but if only one remains, it should
> be about physical fader position, not gain. it should be up to the DAW to
> decide what a fader position means, and the controller's job is just to
> mimic the GUI fader.
> Jörn Nettingsmeier
> Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
> Meister für Veranstaltungstechnik (Bühne/Studio)
> Tonmeister VDT
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ardour-Dev