18 Feb
2010
18 Feb
'10
3:34 p.m.
On Thu, Feb 18, 2010 at 6:38 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Thu, Feb 18, 2010 at 12:32 PM, alex stone
<compose59(a)gmail.com> wrote:
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(a)freelab.epitech.eu> -- <elthariel(a)gmail.com>
Web : http://www.labfree.org/
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev