Skip to main content

Improving Virtual Instrument Support

Posted

Judging from early bird feedback so far, a significant hurdle for new users currently is to deal with external sound generators, namely virtual instruments hosted on a DAW. The latest ReWire support of 1.0.2 much improves the way Synfire interacts with a DAW, but the somewhat cumbersome work required to mirror the DAW's loaded rack of sounds in the form of Synfire device descriptions remains.

There are multiple possible solutions to this and we would be interested in your views and suggestions. Your opinions are much appreciated and will be considered for future development.

The Goal: Automated Sound Swapping

To better understand why this is a dilemma for us developers, you should know that Synfire was designed to have multiple arrangements, libraries and phrase pools opened at the same time in order to be able to drag/drop and copy/paste between them, which is an essential part of the workflow. As different arrangements, libraries and pools also use different sounds, the switching of sounds should happen automatically in the background. You probably don't want to be asked to load/unload presets manually every time you click on another phrase ;-)

The sound management of Synfire is able to silently provide fully automated and transparent access to hundreds, if not thousands, of sounds, provided they are registered in device descriptions. They're loaded only when needed and unloaded when no longer referenced and the user doesn't have to bother about that. If you receive an arrangement or library created by another user (or Cognitone), Synfire will look up the best matching sounds on your rack automatically.

Unfortunately (and interestingly enough), most modern software instruments do not support this over a midi connection, while hardware synths and GM modules/libraries do. Plug-ins are designed to have you manually set them up using their own graphical surface and the DAW will retain these presets. Synfire is unable to take notice of these changes, because there is no technical standard to support this kind of remote access between applications.

The result of this is you have to switch the sounds of plug-ins manually at the DAW side and mirror this change in Synfire.

Well, so far for the dilemma. Now for potential solutions.

SOLUTION A: Standard Rack of Sounds

Load a rack with a couple dozen sounds into your DAW, assign them unique midi ports and channels and use that as your personal "sound server". You will have to register this rack only once as one or more device descriptions and can forget about the details later.

This is fine for musical styles that mainly rely on a known selection of sounds: Orchestral works, Big Band, Jazz Band, Pop Band, Songwriter's Piano/Guitar etc. If you are composing any of the mentioned styles, this is the way to go. The relatively minor effort to move your finished piece to Pro Tools, Logic or whatever DAW for production is nothing compared to the benefits you enjoyed while composing it.

This solution however is less suitable for dance and ambient music, as these styles make heavy use of individually tweaked and customized sounds.

SOLUTION B: Access Ports and Channels Directly

The user enters a midi port (e.g. "IAC Driver:Port 6") and channel (e.g. 12) directly from the instrument's properties dialog and adjusts the playing ranges, instead of picking a predefined sound from the browser. This would allow to skip the creation of a device description and much simplify the initial setup of a new arrangement.

Sounds good? Well, this indeed works nicely with a single arrangement. Once you open multiple arrangements with different port/channel assignments at the same time, conflicts will occur. The phrases picked from libraries and pools would not play the sounds they were designed for. When opening an older arrangement that was created some time ago, it will very likely no longer match your current rack of sounds in the DAW. Lacking a device description, you will possibly not even remember which sound was actually used back then.

IMO, this "quick & dirty" direct setup is still great for new users to get instant results more quickly. We will consider adding this as an intermediate solution.

SOLUTION C: Provide Plugin Wrappers

Cognitone could create a wrapper plugin that hosts the actual software instrument and communicates with Synfire over the ReWire protocol. This would allow Synfire to load/unload different plugins and presets into these "slots" without the DAW taking notice of it ;-) In other words: Synfire would do the "manual" switching for you at the DAW side. The cool thing is that your DAW document will also work standalone, i.e. without Synfire connected.

You would still need to describe your plugin presets once, but the switching/swapping will happen automatically. We are currently evaluating this idea.

SOLUTION D: Make Synfire a Host

This would, to some extent, turn Synfire into a DAW itself. It would be able to access the plugin's presets and save them along with the arrangement. However, Synfire's DAW capabilities will never be able to compete with those of Logic, Live, Pro Tools or DP. It is questionable whether this reinvention of the wheel would be reasonable, both economically and technically. You will want to move your finished compositions to your favorite DAW anyway.

Let us know your opinions and suggestions. This is a very important focus of development, so any comments are welcome.

Andre


Thu, 2009-03-05 - 19:23 Permalink

Solution B would already help a lot. I see the multiple arrangement thing but I dont use it. I sketch all figures in the editor.

Thu, 2009-03-05 - 20:30 Permalink

Hello, Andre. I am a user of HN, but I am considering the purchase of SF.
I agree on the importance of managing Virtual Instruments, and the dilemma involved. I would give you my opinion, but one thing I did not understand: How to handle the
communication between the DAW and SF in "SOLUTION A and SOLUTION B? via ReWire?

Anyway, I think the "SOLUTION D" is the least viable, both for Cognitone (application development) and users (learning to manage other DAW)

Thu, 2009-03-05 - 21:47 Permalink

Andre,

Being able to load sounds "on demand" from within synfire would be fantastic. I use a lot of sounds from samplers (like Kontakt). These don't tend to have "presets" which can be loaded via program change midi messages. You have to browse through a library to load them. Would your Solution 3 be able to handle that?

Tim

Fri, 2009-03-06 - 21:05 Permalink

I seem to like option C.

If I understand it correctly.

Thanks,

dw

Tue, 2009-03-10 - 22:54 Permalink

It took a lot of experimenting to realize this, but I've found Bidule to be a great companion to Synfire. Since you can host a Bidule setup inside a DAW it makes it pretty easy to slowly transition into the DAW as you decide what sounds you want to commit to.

When it comes to the Synfire-Bidule way of doing things, some improvements can be made, but most of them are on the Bidule side.

I think there should be some kind of development summit between Cognitone and the Bidule people.

Fri, 2009-03-13 - 01:45 Permalink

If its going to go past rewire, i think building the host in is the only decent approach... Perhaps a deal can be made with someone like Plogue to integrate some of its functions.

I'd rather see it left as is and have other features worked on for the moment.

Right now, use for film composition is severely limited by the lack of a Time Warp equivalent; the ability to place cues within a container. I'd much rather see this fixed.

Tue, 2009-03-17 - 21:10 Permalink

Option c sounds interesting, perhaps in combination with option d:
What about a small, separate plugin host that works both as a standalone application as well as a subhost. Then per default Synfire could load the standalone version in the background (so the subhost and it's settings appears like just another Synfire dialog to the user, it's almost invisible to him that this is really a separate process.) Alternatively the subhost could run as a plugin itself (like suggested in option c), so people could move their setup into the DAW without reconfiguring it while not having to cope with the DAW at all in the prototyping phase. (Both the standalone version as well as the plugin version are remote controlled by Synfire based on the same sound settings, so there is no difference to the user).
This would also allow to keep all the hosting code out of Synfire - perhaps it would even be possible to cooperate with one of the many people who already built a working and proved standalone/plugin-mode subhost. That could make this option more realistic time-wise.

NaN

Fri, 2009-08-07 - 00:21 Permalink

As the more advanced options discussed in this thread will probably not be on the mid term horizon, could you please consider to add a feature to the instruments tab of a figure that allows to select a sound from the device description list (with it's key ranges, articulations, controllers etc.) and just change the port and channel for the local instrument. This would be extremely helpful as for a certain sound the key switches, playing range etc. are often constant, while the channel and port where the sound source listens in the vst rack can differ from piece to piece (e.g. in one piece I have an Aria instance with a several gigabyte Samplepiano in slot one (channel 1) and a flute in slot 2 (channel 2) and a synth plugin that listens to channel 3. Next time I have a dedicated piano vst on port 1 channel 1 and load 16 orchestra instruments (among them the flute) into Aria on channels 1-16 of port 2.
The flute has still the same key range and articulations as it had in setup 1 it just responds on another channel and another port this time.
Having a "standard rack" as suggested in solution A) would mean that either every instrument has to be loaded all the time no matter whether it's needed or not (not good for big sample instruments) or at least each sound would have to get a distinct port/channel combination, so e.g. you'd have to load three instances of a sampler just because you need the sounds assigned to port1/channel1 port2/channel1 port3/channel1 instead of just loading the three sounds into one multitimbral sampler instance that reacts to port1/channel1-3.

Thanks for reading,
NaN

Mon, 2009-08-10 - 15:47 Permalink

@NaN

A alternative way to achieve what you are suggesting is to copy sounds from existing descriptions to a new description that is dedicated to your arrangement. This also copies the sound's ranges and controllers and everything (albeit not if they are inherited from the device). You can do that in the Audio & MIDI Setup window. For example, you could have a description that includes all your orchestral instruments and use that as a library to pick sounds from as needed. The "GPO All Instruments" device is a good example.

I see the advantage of being able to select and copy a sound template on the instrument tab, though. At this time however, Synfire can't browse the sounds of disconnected devices. I'll discuss this with Andre. Seems like a good idea.

The "Standard Rack" workflow just suggests that you stick to your own convention as to which ports and channels you use for certain types of instruments. You can (and will) certainly replace the individual sounds anyway as your song evolves ( (http://www.cognitone.com/support/article.stml?o=115) ).

Christian

Mon, 2009-08-10 - 23:48 Permalink

Thanks supertonic for the suggestions, as long as the number of pieces is still managable the approach with the description per piece is probably a managable way.
Currently I'm mainly writing things for solo piano so the "rack setup" is rather straighforward. Orchestral stuff should also be managable with your suggested slot per instrument category approach and for synth stuff you'll probably need custom setups per piece anyway.

Thanks for help,
NaN