Re: [LAD] CV data protocol in apps.

2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>: 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(a)openoctave.org development-subscribe(a)openoctave.org