>however, this isn't enough to provide temporal sync to a transport >control, so its not clear to me how the "single bit" method can work >for this as well. after all, the method i outline above is really just >a crude word-clock system (low resolution).
If VST System Link is just another sync protocol, I was wondering how VST System Link differed from, for example, MTC. Steinberg (in their release notes) shows pictures of 4 nodes communicating back to a main mixing console but doesn't show cross digital audio communication between the nodes. It wasn't clear to me from reading their speal whether the digital connection between the nodes just sent clock sync between nodes (each of which were running an instance of Cubase for driving and syncing to VST/DirectX plugins) or if System Link sent both sync and full duplex audio over that link. If it just another timecode protocol, then you would have to have a master node that did the job of actually mixing the analog and/or digital audio signals together that are coming from each node. I don't see the big deal if that's the case, other then the bandwidth increase and less jitter from going away from MIDI based sync. They did mention that you could run a node that served as an effects node, but didn't say whether the digital link used to sync the nodes also had the full duplex digital audio stream as well. I assume as well, that if it did contain the digital audio stream, that it would have to be full duplex to be truly useful, especially if it needed to send its effected signal back to a master mixing node (be it a real digital mixing console, or just another computer node acting as a virtual mixer) for real time monitoring. I am also hoping that they don't force the nodes to have to run an instance of Cubase or Nuendo in order to attach to the stream, if indeed they are streaming audio on that digital link. It would be really nice to have a lightweight driver that taps into the stream and can then be directed to any ASIO/VST based host (ie running Battery standalone, not via Cubase or Nuendo). Buying n copies of Cubase wouldn't be very fun if that's what they intend. Anyway, to bring this back to linux land... >Why JACK? JACK is not a LADSPA host. I do realize that JACK is not a LADSPA host. Sorry for not being more clear. I also may have the wrong idea about what JACK is for, but as a lurker on this list for quite sometime, it appeared to me to function as a multiplexer/demultiplexer for audio apps to JACK into each other. If that observation is true, then it seemed appropriate to have a VST System Link like layer of communication to other nodes that was perhaps native to JACK. Maybe what I should have said was that a JACK client would do this. Can a JACK client be configured to be the master sync reference for all other JACK clients, or is that what JACK is supposed to provide? If my observation is untrue, then a hearty, warm felt RTF is appropriate here :) I don't have any real world experience with JACK or LADSPA (which may be quite obvious) because unfortunately, neither of my "high end" cards (Aardvark Q10 and Korg 1212 I/O) have linux drivers, so as a result, my main studio boxen are all Windows based. Where I think linux could play a role for me and others in my situation is that if I could get a linux box to tap into that ASIO based stream, then I could bridge the best of both worlds. If the communication is full duplex, then all I need is a SP/DIF card in the linux node. The linux node could just simply operate as a plugin farm. In any case, it would be a very interesting feature to emulate in linux land if integration with System Link is not possible because of a lack, once again, of vendor support for linux. I also wonder how latency will factor in with this VST System Link (again assuming the link is also transmitting full duplex audio). db _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
