Anderton

pwalpwal
 
ted, tim, some synths add randomised stuff that is different each playback, so there's a use, but if your premise were true generally why do other hosts offer this? (this = recording the synth out into another audio track) cakewalk's previous explanation was to prevent rubbish users creating feedback loops...

Although I understand this is something some people want, it doesn't get in the way of my working with soft synths for the following reasons.
 
1. If you want to record real-time control tweaks, in most synths any parameter you can tweak in real time is recordable as MIDI or VST automation.
2. If the playback truly does something random, then you won't know whether you like what it does until you hear it do its thing. But that's also the case if you render and listen back. The only difference is whether you hear the change being generated in real time, or hear the change being generated in real time after rendering. So the only advantage of real-time recording is it would allow you to decide whether a part was a "keeper" or not right after it played, instead of rendering first and then evaluating.
3. You can always use the external insert to do a physical loopback. It requires going out of the box, but it works.
4. Jack Audio supposedly has a 64-bit version under development so you can do what Soundflower does on the Mac, which is more sophisticated than simply recording an instrument out.

Most of the soundcards these days have software which will allow you to do this internally.  for example in MOTU's units, simply choose RETURN as your input and you will record the output channels of the MOTU.  you'd need to silence the other tracks, which might cause you a problem if you're working to the internal metronome or if you're recording anything based on playback of other tracks, but those could also be routed to alternate outputs in some mix software or in hardware using alternate routing (but that's going to be the case with physical loopback as well - you'd need to use alternate outputs somewhere if you want to loopback ONLY the synth, so you have to have a soundcard with multiple outputs).

There are other problems with that approach.
 
At the moment, Sonar has pretty clean data flow model:
There are input MIDI and audio data. These input data can be recorded to the tracks. At the same time, they can be sent to real-time FXes and synthes, the result is collected and is sent to buses, which can be cascaded as you want.
 
In that model, synchronizing everything is a transparent job. Taking delays/buffers/processing time/look ahead information into account, it is possible to calculate all required compensations predictably well.
 
Let say you input MIDI, which you process with some Synth, record it's output, send this output to FX, send the result to some bus, send it back to some track (yet another thread with "great workarounds"), process it again and record yet another result.
 
No loops, no feedback, you have routed everything correctly. But... how all that recorded information should be synchronized? I see the only possible answer: "we do not care, you get what you have asked for and you are on your own...". Because in case you put Synth output in sync with MIDI (compensate for processing time), you are not able to "play" them both. In case you do not compensate, it is out of sync with other audio (which is compensated). Up to some level, (some) people will accept the result (and sync compensate manually when needed). But I guess there will be 100s threads with complains.
 
 

Adq

Beagle
 
Most of the soundcards these days have software which will allow you to do this internally.  for example in MOTU's units, simply choose RETURN as your input and you will record the output channels of the MOTU.  you'd need to silence the other tracks, which might cause you a problem if you're working to the internal metronome or if you're recording anything based on playback of other tracks, but those could also be routed to alternate outputs in some mix software or in hardware using alternate routing (but that's going to be the case with physical loopback as well - you'd need to use alternate outputs somewhere if you want to loopback ONLY the synth, so you have to have a soundcard with multiple outputs).

I did it with Focusrite, but there is annoying latency added, maybe i didn't find the best way to do it...
But it is obvious that you can't beat doing it inside the DAW.

Yes, your latency would have to be set to the lowest possible setting in order to do this without having issues.
 
I'm not advocating this is a better alternative than inside the DAW, I'm simply offering advice on how to do it with the current programming of Sonar.

Very good point Bill.
 
I fully agree with Craig regarding the "randomization" factor.
 
How do you know you'll like what you record until you play it back? If you don't you'll have to record it again.
 
How is this any different to freezing a synth (which in itself is a lot quicker than recording in real time) and auditioning the result (complete with randomization)?

Bristol_Jonesey
Very good point Bill.
 
I fully agree with Craig regarding the "randomization" factor.
 
How do you know you'll like what you record until you play it back? If you don't you'll have to record it again.
 
How is this any different to freezing a synth (which in itself is a lot quicker than recording in real time) and auditioning the result (complete with randomization)?

This is part of my thinking too.  If there are random nuances in the way the midi translates to the softsynth....and since the keyboard is actually playing the softsynth via midi....it would seem to me that if you record the midi data...then play it back thru the softsynth, you could play it back via the midi track multiple times and you would have the "different nuances" that has been talked about.  I have never realized these nuances myself...but then again, I'm not a true keyboard player.  I can play keys, but more of a guitar player.
 
I can understand how an analog synth could sound different every time you play the part live...but with a digital keyboard that is just transmitting midi to a sound generator (via hardware synth or softsynth)...it's hard for me to comprehend how the performance could be different, whether played with your hands or the midi recorded info playing it back....I would think it would be the same data info.  Someone please correct me if I'm wrong.

And finally imagine you want to record performance, that involves both heavy synth parameters changes, and huge random changes. Glitch synth, for example. You can be very satisfied by what you have record, but you can never get the same result again if you only record parameters. And the reason is that random changes can influence your performance, and with other random seed you performance will have no sense.

Adq
1. Record+Listen -> Good -> Ready
2. Freeze -> Listen -> Good -> Ready 1 is faster.

 
From a theoretical standpoint, yes. But I have to wonder how many people here have actually tried to capture randomness as part of their work, and dealt with the reality of the situation.
 
(1) is faster only if you trust yourself that you were able to evaluate the part you played while you were recording, believe all the random changes were correct, and are sure you will not need to redo the track. Otherwise, you will need to re-record it again, hope you get your moves right, and evaluate. Every time you do this, you run the risk of not playing the part perfectly and having to start over again.
 
On the other hand with 2, once you get the part right, you can freeze and evaluate. Don't like it? Undo, freeze, evaluate. You can keep undoing and refreezing until you get a part that's just right, without having to play it over and over and over and over and over and over. 
 
I'll take freezing over real time recording any day, because it can generate possibility after possibility until one comes along that's perfect - and I only have to play the part right once. And of course, MIDI can record controller tweaking so there's absolutely zero reason I would need real-time recording for control tweaks.
 
As to real-time recording being a "professional" feature, one of Cakewalk's many truly professional features is how well it handles track sync, sample accuracy, and delay compensation. As pointed out by azslow3, you jeopardize that by unbalancing the system.
 
To me, recording VSTi audio in a way that forces you to re-do a part every time if there's one little aspect you don't like - whether it's the way you're playing or the effect of the randomness - is pointless. I would hate to see Cakewalk spend their development time on something that offers potentially faster operation in one very specific set of circumstances at the expense of jeopardizing timing stability.

You didn't understand me right. I mean Record+Listen is faster when you have midi recorded already, and want to find sweat random take. Now you need Freeze then listen, and it can be 10 or more times, and Freeze could take considerable time if you use huge effects set on the synth. With recording possible you just start recording (you do nothing, just listen), if you don't like it, you just stop and start recording again, if you like it you are done.
It is more than common practice in electronic music when you use glitch synths. I use it always, in every project, and it is not something weird, but very usual electronic music. And in other post I have described situation when you can't achieve best result without possibility to record synths' audio.
I understand that it will never be implemented in Sonar, but the fact is that in routing field Sonar is worse than almost any other DAW, just because of functionality lack. It doesn't prevent me to love Sonar very much, but it is the fact.

Adq
You didn't understand me right. I mean Record+Listen is faster when you have midi recorded already, and want to find sweat random take. Now you need Freeze then listen, and it can be 10 or more times, and Freeze could take considerable time if you use huge effects set on the synth. With recording possible you just start recording (you do nothing, just listen), if you don't like it, you just stop and start recording again, if you like it you are done.

Okay, I didn't realize you assumed a part had already been recorded. I thought you were talking about true real-time improvisational recording, where you were playing and listening to a random overlay. 

Jeff Evans
Adq has hit the nail on the head. Where this feature comes into its own is when there are random elements at play and the fact that you may react to those random elements and as a result of hearing something random you do something else as a result.

But he clarified the use case I was addressing by saying the part was already recorded ("I mean Record+Listen is faster when you have midi recorded already, and want to find sweat random take"), so he's not going to be interacting with the part, only processing an existing part. 
 
For what you're describing (and a different use case he described), I could understand the concern if it wasn't possible to achieve the intended goal with SONAR, but you can. It just takes either a few clicks for software loopback, or two patch cords and inserting a send for an external physical loopback. That will hold me over until a 64-bit version of Jack appears (of course there are zillion ways to do loopback if you run WDM, but I prefer ASIO).

smallstonefan
Say what you want about freezing - the point is this is a NEEDED feature for those of us that want to capture that creative performance by "playing" the randomness of a synth.

I mentioned freezing only in the context of being able to overlay randomness on an already played part so you could capture a random sequence of events you liked. If you want to play the synth, you can follow the other loopback techniques mentioned in my previous post. There are other DAWs that implement real-time recording more elegantly, but SONAR doesn't lack this feature. What it lacks is a more streamlined implementation of this feature. As a result, I'd much rather see development effort spent on functions that SONAR actually doesn't do, like a "drum machine mode" for the PRV.

The only thing required to safeguard loopback is that the armed/recorded track be muted. Internally this could be interlocked to the track input being a "loopback" and could also allow for tactical loopback (one track, buss, etc.). With other methods the safeguard is user awareness, and the loopback method requires a lot of work (and not all options are feasible). There are already options to achieve loopback, but a method internal to SONAR would be highly preferred.

There is nothing special or particularly clever about feedback detection :)
All it requires is checking a circuit to see if it loops back on itself. SONAR does feedback detection in the output routing UI today - you cannot route an output to a bus or sidechain input if that would result in feedback.
Recording virtual inputs (or rather synth outputs) is trickier than it might seem although the OP looks at this as a "basic" feature. Recording is quite deeply integrated with hardware inputs in SONAR since its the way it was implemented decades ago. It has to support all the recording workflows, punch, looping etc but with virtual inputs. Not that we can't or won't do this but it requires effort and planning. Its not something we can just pull out of our hats in a couple of days :)

I still question the wisdom of spending time solving a problem for which solutions already exist.

sharke
There is also the Vonexgo Recorder and Tape It, but we really shouldn't have to use cables or 3rd party plugins for this.

What's wrong with these plugins? Voxengo stuff is top notch... FL Studio a built-in plugin to record any output same thing as Voxengo but they provide the plugin.
Agreed a live mode would be nice but a plugin on the master should capture a perfect digital stream.