When you hover over the play button it tells you that it doesn't regenerate "unless regeneration is required"
What does this really mean because if you load an existing song that is not frozen and press play without making any changes to the song then it always regenerates anyway as shown by the progress bar at the top of the screen. The next time you press play it doesn't regenerate.
I know you can stop regeneration by freezing but what is the point of "unless regeneration is required" when it seems that unfrozen songs always regenerate the first time they are played after loading. This means that if I forget to freeze a good arrangement before saving it is going to change the first time I re-load and play it.
Tony
I think you've answered part of your question by describing the normal behavior of BIAB. The message also refers to the need to regenerate a song each time you change it (except for the MIDI melody or soloist). Change a chord, add a part marker, change the tempo etc. and the song will regenerate even if you click on Play.
I think you've answered part of your question by describing the normal behavior of BIAB. The message also refers to the need to regenerate a song each time you change it (except for the MIDI melody or soloist). Change a chord, add a part marker, change the tempo etc. and the song will regenerate even if you click on Play.
Thanks Matt but I don't think this adresses my question.
If it's normal behaviour to regenerate when you load and press play for a song that hasn't been modified in any way then why does the Play button hint say "play song without regenerating unless regeneration is required" There seems to be no way of ever playing a song without regeneration immediately after it is loaded unless it is frozen. I, for one, never realized that and it's important information for the times anyone forgets to freeze their hard won arrangement before saving!
Tony
Tony, you are correct about this: There seems to be no way of ever playing a song without regeneration immediately after it is loaded unless it is frozen. I'm not sure what to say except that it has always been this way since the RealTrack feature was introduced ten years ago. I guess we are just used to it.
There used to be only one Play icon, and it regenerated or not as needed. When they made it two icons (Play, and Gen/Play) with the GUI revision a few years back, I think they were trying to make this clearer and added the tool tip.
I'm sure there is a technical explanation having to do with how a song is loaded. If you look at a song file with and without frozen tracks, you will see that the frozen track song is much larger, because the audio has been saved (apparently).
I always took it to mean that "Unless Regeneration Is Required" meant "if any tracks are not frozen".
The last sentence in the hint seems to reinforce that theory.
I always took it as meaning; If I made any changes to unfrozen tracks it's going to regenerate every unfrozen track. And, if I have not made any changes it's just going to replay the previous arrangement.
So, if I have not made any changes, and I am intending to regenerate for a new arrangement (for different drum rolls, for example), pressing the play button will not get the results I want.
It reminds me to press the regen button and also check what I have frozen.
Using ASIO with tracks frozen or unfrozen mine still takes 4sec to start play by double click chord or spacebar or play button, it takes near as long as Generate/Play button, looking up on the very top left of the window "Generating arrangement... please wait" each time it tries to play.
If it's playing from RAM it should be instant, there should not be any generating going on.
Even with all midi tracks it's the same.
The Mac version of BB is instant !
My experience is that the song regenerates the first time it is played in a session, but if no changes are made, subsequent plays in the same session do not regenerate and it will start playing a little faster. This is useful in a rehearsal situation.
This is how fast it starts on Mac
Dropbox
BBMac_InstantPlay.mp4 This is how slow it starts on Win
Dropbox
BBWin_InstantPlay.mp4
Interesting. Does the Mac version have the same settings in Preferences, RealTracks?
Are the computer specs almost the same? CPU, ram. etc.
Is anything running in the background in the PC that is not running in the Mac? Anti-stuff?
The BiaB in my Internet computer (Intel 3.20 GHz - 64 bit- 8 gigs of Ram) plays almost as fast as your Mac. Of course I have all of my anti-stuff running in the background.
My off-line music computer (Intel i7-3.40 GHz - 16 gigs of ram) is as fast as your Mac. It has nothing running in the background.
Both machines are running Win 10 Pro.
It would be interesting to see what others are getting.
PS - Pipeline, I am not doubting your test results. I'd like to find out if they are typical or not.
This is not right Pipeline and I went over this in your other thread about it. I know you're very good with computers and I hesitate to say this but you have overlooked something in your Windows Biab config. 4 seconds for the second Play is ridiculous. Remember the WASAPI thread? I got Biab down to 30ms using MME on Win 10 from hitting Play which while not "instant" is pretty darn fast. ASIO would be around 5-10ms which is probably where your Mac is.
Proof? Who else has this problem?
Bob
The Mac is running on an old Win PC i3 3.2GHz 4GIG Ram,
the Win PC's are i5 3.3-3.5GHz 8GIG Ram.
As I said it should be instant if it's playing from RAM.
When ReWire is implemented and BB is a slave, you press play on your DAW there should be no delay start, you want it to follow the DAW instantly, but it's going through some routine, that needs to be bypassed and like just play already ZZZZZZZ.
"Generating arrangement... please wait" no sorry, what arrangement ?
So I think that is going to have to be fixed.
It's not using 16GIG of RAM, it's not using 100% CPU
RealBand plays when double click on the chord sheet, though it still has the same highlighting bug from 1907 when you double click to play from that chord.
OK, perhaps, the thread has wandered slightly off course, but this is my take - and it's hypothetical only.
To evaluate, I created a 32 bar song, 3 repeats, using RealTracks (_JazFred.sty).
Saved, but Not generated. File size: 3292 bytes
Generate song and save. File size: 3292 bytes
Freeze tracks and Save, File size: 114656 bytes
The frozen song size of 114656 bytes cannot realistically contain much audio data in such a small file.
So, back to my theory:
RealTracks are made up of multiple sound 'phrases' played by musicians. Each phrase may be multiple bars in length.
When you generate, BiaB uses an algorithm to decide which phrases to 'glue together' to make up the entire song. It doesn't need to remember which phrases it used, because next time you generate, it (usually) produces a different set of phrases.
However, if you freeze the tracks, BiaB needs to store exactly which phrases had been used in the previous generation, so it can glue them together in the correct sequence and therefore repeat the performance, note-for-note.
The extra data in the file is a template of exactly which phrases were used to make up the now frozen song.
So there is still a requirement to select all of the required audio phrases and 'glue them back together', and that takes time.
So playing a song that has been frozen does not guarantee instant playback. Of course, the regeneration is handled in a separate thread, so playback can start once the software has decided that it has enough headway to complete the background generation before running out of buffers, and that's why on slower machines there is an option to turn off "Speed up generation of RealTracks" (incidentally, is this option available on a Mac?)
So I think that the song actually gets 'generated' every time, meaning that the audio phrases still need to be extracted and glued together. Maybe Mac's do this without the separate generate thread?
Yes the frozen SGU 114656 bytes just contains the position and bars of the ReaTracks/Drums files used, thats why you can fool it and replace the RealTracks folder with the Direct Input and now you will have Direct Input Instruments.
So when you open the SGU hit Play it needs to piece Humpty back together again......... then play.
But once Humpty has been pieced together he sits in Ram. If you look at your the Process in Task Manager you will see the amount used by the RT&RD's, if you add more bars to the song you will see it grow in Ram.
Now double click on a chord the RAM stays the same amount so BB seems to be just snooze then play.
1:
Is "Speed up generation of RealTracks" option available on a Mac?
But once Humpty has been pieced together he sits in Ram.
2:
Do you know this absolutely for sure, or is this a presumption? This is not a criticism, just a genuine question that I don't know the absolute answer for. Maybe the generated data is not memory resident?
3:
And even though the song might now be in RAM, what is there to tell BiaB not to
replace it, the next time play is pressed? BiaB might not 'remember' "Oh, I've done this before" and create it again from the template.
So many questions, no proven answers.
I always took it as meaning; If I made any changes to unfrozen tracks it's going to regenerate every unfrozen track. And, if I have not made any changes it's just going to replay the previous arrangement.
So, if I have not made any changes, and I am intending to regenerate for a new arrangement (for different drum rolls, for example), pressing the play button will not get the results I want.
It reminds me to press the regen button and also check what I have frozen.
That is what I have always assumed to happen but I think we are both wrong because you can see the song regenerating in the window at the top of the screen when you first load and hit Play with an unfrozen song.
Come on PG! It is your wording that is causing the confusion. Join in the discussion and tell us exactly how frozen/unfrozen/play/generate and play works.
Tony
"But once Humpty has been pieced together he sits in Ram."
"The program already runs 100% in memory.."
Yes, that's the program. That does not guarantee that every piece of data it creates runs 100% in memory though. Maybe it does. My point is that I don't categorically know the answer, so I cannot make this claim.
bbw2 generates into AppData\Local\Temp
if you open it while generating tracks or MultiRiffs you will seen.
To see if bbw writes anything else outside of ram have a look in the BB folder, Temp and song folder, list by recent date.