Re: [LAD] CV data protocol in apps.

On Thu, Feb 18, 2010 at 6:38 PM, Paul Davis <paul@email-addr-hidden> wrote:
> On Thu, Feb 18, 2010 at 12:32 PM, alex stone <compose59@email-addr-hidden> wrote:
>> So it's feasible to create another type of port,  (CV/Fs), without
>> crippling something else in jack, or damaging the current API?
>>
>> If so, surely that would enhance further Jack's capabilities, and open
>> it up to more options for devs and users alike. Even outside my
>> current setup, and as a user,  i can see this as an efficiency
>> improver for the likes of automation in Ardour, increased control over
>> synths, etc..
>>
>> We have audio and midi. A "data" port seems a natural addition,
>> particularly for modular setups, but as a generic model as well.
>
> there seems to be some confusion.
>
> there are 2 kinds of data flows:
>
>  1) streaming - there is 1 value per unit of time
>  2) event-based - there are N values per unit of time where N is an
> integer starting at zero
>
> what are the units of time? for what we currently call "audio" data
> flows, a unit of of time is the sample interval. audio data is defined
> as 1 floating point value per sample interval.
>
> the options to extend the types of data are, therefore:
>
>   a) defining a different time interval, and the data type that will
> be provided for each such interval. this is effectively "reduced
> sample rate streaming data"
>   b) defining another event based data flow, like MIDI, in which
> events are discrete and (most often) sparse
>
> i personally do not believe that there is much need for (a), but i'm
> willing to be shown to be in error.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

Hello,

There are some interesting point of view in this thread:

- There's a potential problem with the complexity of a big synth using
this mapping (anyway, big synths are almost every time complex to map
to the control system, be it midi or anything else)
- Jack midi infrastructure's potential is maybe underestimated, and
using it we could implement something that could allow more than 8bits
messages. This may become necessary at some points (non-chromatic
frequency notes, precise control of parameters, etc.)
- The straight forward features of CV-like flow and their "physical'
property could be used in interesting ways by users and developpers
(kind of related example is reason)

It's interesting to note that all of these problematics have been
discussed and/or adressed in lv2, maybe this work can be used in jack
for the benefit of all ?

Regards,

-- 
BALLET Julien
Head of LabFree,  Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.ballet@email-addr-hidden> -- <elthariel@email-addr-hidden>
Web : http://www.labfree.org/
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev