[LAD] CV data protocol in apps.

alex stone compose59 at gmail.com
Thu Feb 18 12:15:14 UTC 2010


2010/2/18 Jörn Nettingsmeier <nettings at folkwang-hochschule.de>:
> On 02/18/2010 12:18 PM, alex stone wrote:
>> I will clarify here that i'm talking about a user experience, before
>> the discussion gets into jousting with white papers.....
>
> that's what i was interested in, too. can you describe the advantages of
> the non-mixer approach (which i haven't tried yet) to, say, ardour
> automation?
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

Wouldn't be a fair comparison, as my setup is modular, and Ardour's is
monolithic. However Ardour's automation always frustrated me for my
particular use case. That's down to pilot preference, so any
comparison would only be based on that.
Considering the CV approach to midi port setups, and their 16
channels, it might seem a lot more work to patch 1:1. But it isn't
(imho) when you take into account the separation of channels, and
multiple assignments neccessary when using a midi port as a data
stream (sorting out the CC's at either end, etc...). Given the volume
of ports, tracks, channels i'm using, for MY use case, a 1:1 data
route is a simpler, and faster setup, as in the case of ND and NM
communicating with each other.

And of course, 1:1 means i'm only building what i need, at the time.
No multiple channel ports.

I'm not weilding an army of synths like it seems most users are, so
using a single CV to a single function in a mixer strip, or multiple
CV lanes to components in a synth may not seem so attractive for those
users.

I'd also accept that my preference for a simple record as you go, and
tweak the parameters a bit along the way may not be the "normal" use
case for most users, who employ multiple plugins, synths, etc. CV fits
nicely in my user experience so far, and the lanes in Non-Daw are
visually "quick" to identify any anomalies, or where an audio region
needs a bit more editing. But then that's to do with the design of the
app, for MY use case, so only a part of the user experience, related
to using a CV framework.


I'm beginning to regret i ever posted about this, and will be more
selective with my enthusiasm in the future.

Alex.
-- 
www.openoctave.org

midi-subscribe at openoctave.org
development-subscribe at openoctave.org



More information about the Linux-audio-dev mailing list