On 03/05/2014 08:22 PM, J. Liles wrote: > You realize that I don't get paid for this, right? I mean, it does me no > good if broadcasters use Non. I want it to be useful to people, sure, > that's why I released it under the GPL, but I don't do broadcasting (and > have no intention of ever doing it), so not only do I have zero > incentive to slant the software in that direction, but I have no > experience with that workflow.
That's why I asked originally about the API for the modules :). I'm no coding hero but little things I usually can fix up. > Yeah, and that's why I'd like more information, so that I could perhaps > design a more general solution that would encompas that workflow. > Currently, I find the easiest way to deal with these kind of auxiliary > mixes is simply to use multiple instances of non-mixer, one for each > purpose. Keeps things organized (but doesn't map as well to a MIDI > controller, obv). I have played a little bit more in the meanwhile with NON-Mixer. How about adding a fader-view knob and fader-view "Send" button to the AUX module, both MIDI-controllable? With that solution, the BC workflow can be emulated by simply using an AUX bus as main bus. And (as far as I know recording workflows) it would be as useful to recording people as to my understanding, the big expensive studio mixers do have send buttons for each AUX bus in addition to the send knobs, so the producer can pre-tune and activate on the press of the button. An additional custom label which also appears above the knobs on the fader-view would be cool too - saves people from sticking masking tape to their PC monitors :D. -S -- (o_ Stefan Gofferje | SCLT, MCP, CCSA //\ Reg'd Linux User #247167 | VCP #2263 V_/_ Heckler & Koch - the original point and click interface
smime.p7s
Description: S/MIME Cryptographic Signature
