An idea

+1

Routing MIDI from one track to another is very easy inside REAPER, and it is also possible in Sonar.

Jason, I see your point, but what you are suggesting effectively boils down to a return to the manual MIDI-based setup. 

There are fans of hardware modular synths who don't mind writing down knob positions and making photos of their patches to "save" them. This manual approach certainly has something to it, but it can also be extremely tedious, distracting and error prone. 

First off, let me reply to some of your points directly. After that I will elaborate a bit on the vision I have. Basically what you are asking for is already there. There are a few bugs left, but the effort to iron those out easily outweighs the benefits.

All the Synfire project would care about is the Id of the particular drone and instrument is assigned to. That's it.

It already works exactly this way. 

No dependencies between the Synfire project and the drones.

Once you have IDs, you also have dependencies. It doesn't make any difference how the IDs are created and what they look like. They need to be kept matching in both files.

No loss of drone connections

Provided the IDs are matching, the connection can't get lost. The connection issues have been ID issues.

Users should use drones to route MIDI to DAW tracks. 

Not all DAW support that. AudioUnits not even support MIDI out. Synfire would be pretty useless on a Mac.

Now for the vision: The engines and drones are not about hosting plugins. They serve a seamless user experience and integrated overall workflow. Being able to start with rapid prototyping on the fly in an engine and then relocate a mature project to a DAW to refine it - by means of a few right-clicks only, without the need to export! - is a huge benefit (you can even move it from one DAW to another, again without the need to export anything).

The ability to get audio signals into Synfire opens up a whole world of future possibilities (automated sound categorization, spectrum analysis, for instance).

The point of the drones is to have direct access to the physical instrument, rather than using a blind 1982 MIDI cable wired to a black box that is entirely out of Synfire's control and depending on human interaction. Dealing with big orchestral setups this way is a nightmare.

You seem to be viewing Synfire mainly as a sidekick to your DAW, possibly for enhancing existing projects, but that's only one of many uses. Using a DAW has many disadvantages compared to using the engine, at least in the beginning stages of a project:

• High latencies
• Slow transport response times
• Switching back and forth between Synfire and DAW
• Plugin editor not accessible
• Suboptimal sync during recording
• No instant availability of new ports when needed
• Keeping project files in sync, etc.

When I start a new project for fun, I never use a DAW, because I want to focus on the music. Instantly. Basic effects routing is sufficiently supported by the engine to allow for dynamics processing and a wet mix. That's pretty sufficient for composition and prototyping. 

On a side note, the bare MIDI setup also has been an economical disaster. The majority of all users had serious issues with that, could not even get it working after days of fiddling. It was a permanent deal killer and a constant source of frustration. There is no way back.

Those couple bugs left are nothing to worry about. Routine. I am confident you will better understand my vision, especially regarding the seamless workflow, once the new videos are ready. 

Not all DAW support that. AudioUnits not even support MIDI out. Synfire would be pretty useless on a Mac.

But where MIDI out is supported, it would be a nice option to have.  There are some plugins that don't work so well inside the drone, and routing the MIDI from the drone to another DAW track would be a workaround for these.

... OK, looks like I spoke too soon.

I just gave it a try in Sonar and routing MIDI from the drone to another synth track already works.   Nice!

You always have the option to use a drone for MIDI only: Just load a dummy plugin that does nothing (maybe a simple gain control set to bypass).

If this use case happens to become popular, I could enhance the drones to support a MIDI-only mode out of the box. Those ports could appear in a differnt color in Synfire ... anything is possible.

If this use case happens to become popular, I could enhance the drones to support a MIDI-only mode out of the box. Those ports could appear in a differnt color in Synfire ... anything is possible.

I would appreciate that. It should be possible to work directly with empty drones and DAW-internal MIDI routing since still some plugins can't be loaded into the drones or do not work properly that way. Being forced to load a dummy plugin into the drone is yet another workaround and it would be nice if that could be avoided.

would it be possible to make SFP a VST plugin. seems like that would solve everthing. ;)

would it be possible to make SFP a VST plugin. seems like that would solve everthing.

That would even be more complex and harder to get right, because a plugin lives in an extremely limited sandbox.

To answer your question: For a very limited subset of its functionality, yes, perhaps. Some kind of super intelligent step sequencer. But, all technical problems aside, this would no longer be Synfire anymore.

I don't view Synfire as a tool for generating sequences in a DAW. There are plenty tools that can do this already (Catanya, Maschine, Numerology, Noatikl, Bidule, etc). Their terminology and mechanics are sufficiently linear enough to fit the plugin paradigm.

I rather envision Synfire on two or three 27" monitors, hooked to a physical rack of engines with gigabytes of sample libraries loaded, for composing epic orchestral movie scores, commercial ads, tv and game soundtracks, etc. Work that requires a composer to lean back, think, make a move here and another move there. I think you get the picture.

It's great that Synfire can be (and already is) used in many other situations, but it would be a bad idea to cripple it in a way that kills its original vision.

+1

;-) minkepatt

Everything the SFP engine does I can do just as easly with my own DAW (Ableton, Reaper, Sonar, etc.)

Sure. However there are other workflows that mainly focus on (and spend 90% of their time with) assembling the actual music in Synfire (harmony, phrases, textures, instrumentation), rather than tweaking the mix.  Starting with a new idea from scratch is much easier using the engine. It's all in a single self-contained project.

hey

It would be very nice with a MIDI-only drone.

Just load a dummy plugin that does nothing (maybe a simple gain control set to bypass).

By the way, it seemed to work without even a dummy plugin.  I just added the drone, left it empty and routed the MIDI out to another synth and it worked.

By the way, it seemed to work without even a dummy plugin. I just added the drone, left it empty and routed the MIDI out to another synth and it worked.

Yes, this may work. But if I remember correctly (will check it again later) the instrument indicator at Synfire remains red (indicating that no sound was found) when the drone is operated empty. Only if a plugin is loaded into the drone the indicator gets green.

I'm not sure what consequences this have. When the instrument indicator is red Synfire probably will look for a "better sound" on every start of the project. There should be created a clean solution for operating the drones this way.

Jason, thanks a lot for taking the time to reply. I appreciate this discussion.

As for the manual setup, I don't think I underestimate the effort. You are a very experienced power user who's already familiar with the concept and can deal with it. This is not the case for the majority of new users. Synfire starters expect a double-click-and-go experience. The advantages of having a self-contained project that includes everything are priceless (with private plugins, a project does no more depend on a separate rack).

Videos don't help much with an inherently flawed concept. Despite of more than a dozen instructions, conceptual articles and videos (all dealing with midi setup exclusively), most people got frustrated and gave up on it. This is a proven fact. Sound output is expected to work out of the box. Synfire should be fun, not work.

Even I got frustrated myself, because I increasingly felt uncomfortable with opening projects saved only a few weeks ago. Needless to say that, due to my overall workload,  I failed to stick to the discipline that is required for householding with all the different shared racks, loopback ports and Synfire files. 

You are correct that the engine is just a minimal DAW. The actual difference however is that it is under 100% control of Synfire and therefore integrates seamlessly with current and future workflows. 

With the current audio system, you are free to choose between various options:

1. Compose in a self-contained arrangement using private plugins
2. Quick & dirty prototyping using a shared rack (engine or DAW)
3. Work on DAW-based projects paired with Synfire using the drones
4. Do the same based on MIDI-only drones
5. Hook up to Synfire in other ways using MIDI loopback or external hardware
6. Move a project freely between different DAWs and engines

Hey, to me that sounds like music maker's paradise! I really don't see any reason to change this. Once the bugs are ironed out, Synfire will be more powerful than ever before.

Yes, this may work. But if I remember correctly (will check it again later) the instrument indicator at Synfire remains red (indicating that no sound was found) when the drone is operated empty. Only if a plugin is loaded into the drone the indicator gets green.

This would be changed for a MIDI-only drone. It's a minor modification only. I think I can include it with the next update.

I really don't see any reason to change this. Once the bugs are ironed out, Synfire will be more powerful than ever before.

+1

Let me say that I really appreciate your visions and I think a man should follow his visions :thumbsup:

Sure, there were some bugs but everyone can see your hard work to iron that out.

Andre, I am one of those people that gave up on synfire using the old midi loopback workflow. I ended up just making really simple phrases and transferring them from sf to live as midi files then building the song up in live. Wasting most of the power of synfire.
Now since the Release of the new beta versions, I've started using synfire a lot more. In fact I find the new workflow so much simpler, I am looking into how much I need each vst that doesn't scan an produce a full device description. I've already dropped some for that reason.
I'd still vote for a midi only option in the drones for linking into live's instruments and possibly my external synths.

Keep up the excellent work, and everyone should remember this is all still a beta so we were always warned there would be bugs.

I posted this last February.  I think the ideas still apply to all of us who only want sync and midi with no drones or servers.  Issues like Anticipative fx are key as they can greatly improve performance. The sync aspect from this post may no longer apply but the rest does.

This method has a number of advantages over what has been discussed so far.

Thanks for the update, I hope this backup system will make this lady more workable.

 

I had a thought about the vst issue.  As a very simple solution couldn't the vsts simply be  midi file players that stream the midi data from memory or even disk that is being altered by synfire as the composition is edited?  One would be placed on each track above the synth it is controlling with a setting to specify which track it is assigned to in Synfire.

 

Synfires sync to the daw could then be set so that MTC controls the transport position, but the transport buttons send midi notes or cc controls that can be leaned in the daw (they all have this abaility for use with mixing control surfaces).  This way there are no longer sync or latency issues as the DAW's latency compendation can do its job.

 

There would still need to be a live midi link so that selected notes would be previewed in the DAW when editing the arrangement but for playback it might be simpler and more stable -- potentially working after a Synfire crash, even if the notes can't actually be edited till synfire is restarted.  This would also be useful if Synfire was no longer needed on the project, during mixing and whatnot -- 

 

This eliminates the problem of rewire, sync and latency. It also gives so daws the ability to run anticipative fx and better conserve cpu when running a lot of fx.  It also would allow a 64bit version of the vst without porting larger portions yet.

 

All that would need to be set in the VSTi would be which track its associated wtith, though it would be very useful to be able to set the playing range, cc's and articulations in the vst so that midi learn on synth vst's coudl be done in the same pass as setting the synfire parameters of each track.

 

MIDI drones are available now:

(https://users.cognitone.com/content/pure-midi-drones)

BTW: The drone works just like every other plugin in the DAW. It's merely a very lean wrapper around the guest plugin. If the DAW supports anticipative processing, the drone enjoys this too. Same for delay compensation and any other technique that might come up.

It's good to hear that it will support those optimizations.  I'm just checking it all out now, but I had such a bad experience with jBridge that I'm always weary of wrappers.  Hopefully this will be less of a problem.

I did notice that rewire no longer shows up in Reaper.  I haven't figured out why yet. (as of b23)

I had such a bad experience with jBridge that I'm always weary of wrappers. 

A 32/64-bit bridge is a different thing at a much higher level of complexity (and its not a wrapper). It employs running a separate OS process in parallel to the DAW, pumping audio signals in real-time back and forth between the two. There are many potential points of failure.

The drone is just a straight VST/AU plugin that loads another VST/AU plugin within the same DAW process. Its CPU overhead is extremely minimal.

@jbone1313:

Why should Synfire care about what that drone contains or worry about finding replacements? If drone Id 2 is open in 6 DAW projects simultaneously, let Synfire send to all!

After I kept this in my head for a while, I wanted to let you know that this really seemed like a compelling idea at first sight (match destinations by user-defined names).

But then I realized it can't work, because the drones are so much more than a simple output-only MIDI data sink (like standard MIDI ports are). Drones are active and stateful members of an arrangement. Synfire communicates in both directions and constantly modifies their contents. In a way they are like files. Accidentally linking to the wrong drone would be fatal. It may work with MIDI-only drones, but those are just one option out of many.

Synfire taking care frees the user from the burden of assigning meaningful unique names to each new port, which would be a tedious and error prone task. 

The remaining issues with drone IDs and opening/saving projects can be easily fixed. It's nothing I worry about.

I like this idea also --- I have a *huge* amount of other gear and outboard gear and having a Synfire dummy plugin built-in would be a lot better than searching for dummy gain controls.  I am still learning the system but I should have some tests done at more sophisticated level soon.