This is a problem I'm returning to after a skirmish with it in 2010, which was put on hold when I transferred to Ubuntu as my everyday operating system.
I've recently upgraded to 2012, and have purchased a number of extra RealTracks, so I'm going through my repertoire updating the songs so as to use RealTracks whenever possible.
The yellow card in the upper right corner of the screen which comes up with suggestions about these changes when you open a file is a handy prompt, and I decided to try running through the whole folder using JukeBox.
I've unticked all the boxes in the "Options for JukeBox" screen, except the "(Preview) Switch to next song after ... bars", and I've set the number of bars to 4.
Every time I try this, BIAB becomes unresponsive after the third song's introduction has been played. I've tried this numerous times, with the same result, and I've just tried the same test with 8 bars instead of 4, and BIAB hangs after the second song.
Is there some way of posting the offending files, so that someone else can check it on a different machine?
I've placed the files on Dropbox, so they're available through the following links:
http://dl.dropbox.com/u/22831598/Link%20to%20Main%20270608/BIABTest%202012/9-20_Special.MGUhttp://dl.dropbox.com/u/22831598/Link%20...RT%5D%20MDH.MGUhttp://dl.dropbox.com/u/22831598/Link%20...205%204.00m.MGUCould some please try these for me?
1. Download the files to (for example) a new folder called C:\BIABTest
2. Run BIAB 2012, and click the JukeBox icon.
3. Untick all of the boxes in the Options screen, except (Preview)...
4. Set the number of bars to 4.
5. Click the "Change Directory" button, and browse to C:\BIABTest (or whatever you've called the new folder).
6. Click "PLAY JUKE BOX".
I think this is due to the time required to generate RT's. You didn't say if these existing songs have some RT's already in them or if they're all midi. If they're all midi then this answer has no bearing on the problem. Biab has not finished generating the Real Tracks/Drums for one song before you go on to another. I don't use the Jukebox so I'm not positive about that but it sounds like it. Biab will allow a song with RT/RD's to start playing before the song has finished generating. If you stop the song before that happens and either hit play again or start a new song immediately it hangs and since the Jukebox just runs from one song to another the generation time could be the culprit and that of course is a function of how fast (or slow) your computer is. Normally, people use the Jukebox to play the whole song and even on a slow computer Biab will have finished generating after the song has played 8 or 12 bars or so. Try extending the number of bars per song to say 15 or 20 and see if that fixes it.
Bob
Thanks, JazzMammal,
I previously tried extending it to 8 bars, and this time it died at the end of the second song.
I've just tried 16 bars, and BIAB died at the end of the sixth song.
I've generated and then frozen all the RT-containing songs before saving them, so I don't think that generation time should really be the issue. When this happened to me that last time (in 2010) I tested it out on two computers with widely differing resources (4 times the RAM and a much faster processor), and found they both got stuck at the same point.
My purpose here isn't to find a way of playing four bars of each piece with JukeBox (a pretty useless activity, I have to admit!), but to point out that I can repeatedly cause BIAB to hang.
I don't think a program should hang like this - particularly one which is used for live performance - and if BIAB is indeed "allow[ing] a song ... to start playing before the song has finished generating" it should be able to deal more elegantly with the consequences.
When I did some semi-professional programming in years gone by, I was delighted to be informed of reproducible problems with my code, as they often revealed problems in sections of code I would never have thought of checking, and which were causing other obscure problems,
Quote:
I've generated and then frozen all the RT-containing songs before saving them, so I don't think that generation time should really be the issue.
Freezing the RTs doesn't remove the need to regenerate the song. Freezing just stores info about how to construct the RTs. It will still take roughly the same amount of time to generate. You could try checking 'this song has playback problems, disable fast re-generation' in the song settings menu and see if that helps. In theory that setting should cause the song to wait until the RTs are generated before playing.
Hi FoxyLady,
Thanks for that information. Hopefully we can duplicate it, and then we could solve it. For testing purposes, could you try pwarren's suggestion of trying the jukebox with the "PRefs-RealTracks-SpeedUp Generation" DISABLED.
This would make generation of all songs much longer, but provide us helpful diagnostic information, to see if they still hang or not.
Hello,
I will be testing this with your examples and my own and submitting information on this issue to the developers.
Thanks!
Quote:
I don't think a program should hang like this - particularly one which is used for live performance - and if BIAB is indeed "allow[ing] a song ... to start playing before the song has finished generating" it should be able to deal more elegantly with the consequences.
When I did some semi-professional programming in years gone by, I was delighted to be informed of reproducible problems with my code, as they often revealed problems in sections of code I would never have thought of checking, and which were causing other obscure problems,
This is exactly what's happening now and maybe your specific Jukebox question is separate from the generation problem and it is fixable but we'll see. When you're dealing with Real Tracks remember those are audio files. Even a super fast i7 with 12 gigs of ram takes time to generate those tracks because they're audio but a machine like that is pretty quick if not immediate.
The generation times issue has been talked about to death since RT's were first introduced several years ago. The "fast generation" feature was implemented maybe two years ago in response to those concerns. If it was simply something in the code I'm pretty sure it would have been done by now. If you stop and hit play again too soon Biab will hang but it hasn't crashed. That had me fooled for some time. I thought it had crashed and got all kinds of freezes and error boxes when trying to close out of the program. Just wait and the song starts playing again. How long is the wait depends on your machine of course and like I mentioned in the other thread talking about "antique" PC's my new machine can generate and start playing a 6 track RT song in about 7 seconds. That's fast enough for a gig. Trust me unless you're truly permanently short of cash, you'll get tired of messing around and upgrade to something fast.
As to the freezing of tracks, that was specifically implemented for live players because real time generation of RT's takes too long on a gig if you don't have the latest and greatest PC.
Bob
Thanks, Peter.
I've disabled the Speed-up generation option, and am running a four-bar JukeBox job on a large directory of songs. It may take several hours, but it didn't crash after three songs this time.
Perhaps you can clarify the meaning of "generation".
I have understood it to mean the process of selecting appropriate RealTracks phrases for assembly into the complete song, and that this would be done every time a song is played UNLESS the part is frozen.
This implies that, if all of the RealTracks in a song are frozen, the decision about what phrases to play has already been made, and the delay between pressing Play and the start of the song relates to the assembly of the phrases.
I can report that with the Speed-up option OFF, the 4 bar JukeBox exercise got through 231 of 233 songs in a folder, without hanging, but it stopped with piece 231 open.
There were two sets of "Large Lyrics" on the screen at the time (I'd previously noted that persistence of Large Lyrics after a song had been closed was a feature of the exercise), so clearly there are circumstances where these aren't shut down with the song itself.
BIAB is able to play piece 231 in the normal way, and it shouldn't have been too challenging, as it only used RealDrums and MIDI - no RealTracks. Piece 232 was all MIDI, and piece 233 was RealDrums and MIDI, and played through without trouble.
Quote:
Perhaps you can clarify the meaning of "generation".
I have understood it to mean the process of selecting appropriate RealTracks phrases for assembly into the complete song, and that this would be done every time a song is played UNLESS the part is frozen.
This implies that, if all of the RealTracks in a song are frozen, the decision about what phrases to play has already been made, and the delay between pressing Play and the start of the song relates to the assembly of the phrases.
Yes, frozen means "the process of selecting appropriate RealTracks phrases for assembly into the complete song" is completed. This is what takes so long each time you hit play and regeneration is performed. Howver,when you freeze the tracks this is already done and playback will be immediate.
Quote:
Yes, frozen means "the process of selecting appropriate RealTracks phrases for assembly into the complete song" is completed. This is what takes so long each time you hit play and regeneration is performed. Howver,when you freeze the tracks this is already done and playback will be immediate.
Although it would take a comment from the programmers to confirm, I believe this isn't quite correct. While the calculations to fit the phrases to the song have already been done the bulk of the work remains. The phrases still have to be assembled from the master audio files and any pitch correction and stretching still needs to be done. It'll be faster, for sure, but not immediate.
Quote:
Quote:
Yes, frozen means "the process of selecting appropriate RealTracks phrases for assembly into the complete song" is completed. This is what takes so long each time you hit play and regeneration is performed. Howver,when you freeze the tracks this is already done and playback will be immediate.
Although it would take a comment from the programmers to confirm, I believe this isn't quite correct. While the calculations to fit the phrases to the song have already been done the bulk of the work remains. The phrases still have to be assembled from the master audio files and any pitch correction and stretching still needs to be done. It'll be faster, for sure, but not immediate.
Paul, I did see you earlier comment here, but I am 99% sure of this response (of course I could be wrong 
). But this has been my experience as freezing the tracks was a life saver to my show providing immediate playback when frozen (~1 sec?). And I do believe this has been confimed by Peter in the past. Heck, give it a try and see. 
FoxyLady,
Thanks. A followup question... Can you also get it to happen by simulating a jukebox, by 1. 1. Playing a song (**not** using jukebox) from the folder that has the 3 offending songs that you posted.
2. pressing the Next button to go to the next song as the other one has just started
Does the same issue happen - a hang (ie without involving the jukebox)
Quote:
Quote:
Quote:
Yes, frozen means "the process of selecting appropriate RealTracks phrases for assembly into the complete song" is completed. This is what takes so long each time you hit play and regeneration is performed. Howver,when you freeze the tracks this is already done and playback will be immediate.
Although it would take a comment from the programmers to confirm, I believe this isn't quite correct. While the calculations to fit the phrases to the song have already been done the bulk of the work remains. The phrases still have to be assembled from the master audio files and any pitch correction and stretching still needs to be done. It'll be faster, for sure, but not immediate.
Paul, I did see you earlier comment here, but I am 99% sure of this response (of course I could be wrong ). But this has been my experience as freezing the tracks was a life saver to my show providing immediate playback when frozen (~1 sec?). And I do believe this has been confimed by Peter in the past. Heck, give it a try and see.
I have tried it. When I click play on a song with a frozen soloist you can see the track generation in the title bar. It is definately faster but still takes long enough to see the info. Peter said in a previous thread that only the info for the track is saved with the song not the actual waveform. Which is easliy confirmed by looking at the file sizes.
Quote:
Freezing wouldn't make a difference, since the BB MGU files don't contain the audio anyway... Just pointers to the audio files.
Quoting PGannon from this thread
That means the track still has to be assembled from the master audio files. I would guess that your PC is fast enough that it seems immediate.
However, in the absence of official confirmation I will label this as my opinion rather than fact.
>> Although it would take a comment from the programmers to confirm, I believe this isn't quite correct. While the calculations to fit the phrases to the song have already been done the bulk of the work remains. The phrases still have to be assembled from the master audio files and any pitch correction and stretching still needs to be done. It'll be faster, for sure, but not immediate.
Paul,
Yes, this is correct. On a fast machine, this appears to be instant, maybe 1-2 seconds until playback starts.
(RealBand is different. It saves the actual audio, so playback there would be instant, and every song is "frozen")
Quote:
So Paul, I guess that answers our question for us from Peter himself. 
I was still typing as Peter replied. As I suspected, your PC is fast enough that reassembly appears immediate. On my PC not so much. 
Quote:
Yes, this is correct. On a fast machine, this appears to be instant, maybe 1-2 seconds until playback starts.
Exactly, Peter. If the OP had a i5 with 8 gigs of ram or my machine, this thread would not exist. Yes, the question comes up all the time "does Biab work on my older machine?" and the answer always is sure it will, no problem. The problem is that question is incomplete. Yes, the programs run fine but do they run to your expectations? That answer is usually no.
Doing normal household stuff on your computer like emails, web surfing, sharing a few photos on Facebook, maybe creating a few Wordocs, stuff like that sure, a 10 year old machine is ok but start doing digital audio work? No way. It will do it but it also spawns tons of threads like this one.
Speed is your friend with computers and digital audio/video work. Gotta keep fairly current or you will just frustrate yourself.
Bob
Thanks, Peter.
With fast generation turned off, I have no trouble in cycling through the three songs.
When I turned fast generation back on again, I was able to play the first four bars of the first two pieces, but when I pressed "Next" at the 5th bar on the second one, BIAB hung - by which I mean that the menu bar at the top of the screen went white, the Title bar included "(Not Responding)" at its right hand end, and the cursor became an hourglass when hovering over any part of the BIAB screen except the title bar. It's not so unresponsive that clicking on the "Close" box doesn't work, however, which is different from the occasional Access Violation, which does require the Task Manager.
Incidentally, if I watch memory and CPU loads with Task Manager while BIAB is regenerating a song, BIAB doesn't seem to be overstretching the CPU or using much system memory - is BIAB being too "nice" for its own good, and being unnecessarily parsimonious with system resources?
PS Since posting the above, I've rechecked my system's performance in Task Manager with this batch of songs, and find my memory was playing tricks.
CPU Usage leaps up to 100% and hovers there or just under until the song starts to play. On the other hand, the usage of physical memory is modest, with available memory dipping slightly, but hovering around 1/3 of the total 1GB.
So it looks as though I'm going to have to dig deep into my sporran and get a laptop with a much faster processor if I'm to get a quick response on a gig, but that I may not need to go over the top with memory capacity.
As it happens, my clarinet-playing colleague has a new laptop which we use on gigs, so mine is used for preparing songs and individual practice, and will only be used on gigs if something bad happens to his one.
Thanks to everyone who has contributed to this thread - I've learned a lot about BIAB while looking into it - and I obviously have to keep Fast Generation switched off.
I still think there's a problem with the underlying Fast Generation code which has been revealed, not caused, by my slower machine. If the "Next" button is pressed after a song has started but before the generation is complete (or the equivalent in JukeBox), BIAB doesn't tidy up properly before starting on the next song, and trips itself up.
Quote:
PS Since posting the above, I've rechecked my system's performance in Task Manager with this batch of songs, and find my memory was playing tricks.
CPU Usage leaps up to 100% and hovers there or just under until the song starts to play. On the other hand, the usage of physical memory is modest, with available memory dipping slightly, but hovering around 1/3 of the total 1GB.
CPU ramping up to 100% is not a bad thing. (Unless it goes there and stays there...) Using 100% of the CPU is exactly what we want to see when performing such tasks. Good thing. But read on...
Bear in mind that there *must* be some of that 1gig left untouched by the application as the Operating System is going to chew up quite a bit of ram. Also, if your computer uses onboard video with ram sharing, there will typically be a chunk of your physical ram set aside for the video only, this can be as much as one forth of the 1gig total. An application such as BiaB will get a portion of ram, but if that is filled, then the OS goes into the disk swap routine in an attempt to provide more ram space by using part of the hard drive. This swap can lead to timing probs with realtracks. The real answer to this problem is to install more physical ram in the computer. Adding a nother gig is a great idea and doesn't cost all that much these days. There should be a decided difference in performance when using 2g as vs the 1g, matter of fact, 1g is considered barely enough to run the operating system these days and that goes even if running the lowly old XP. Upgrade your ramcount.
Quote:
So it looks as though I'm going to have to dig deep into my sporran and get a laptop with a much faster processor if I'm to get a quick response on a gig, but that I may not need to go over the top with memory capacity.
Rethink on the ramcount front. "You can never have enough physical ram"
On the other hand, there is no need to overload the ramcount either. But most puter deals out there do not include enough ram to begin with at purchase time for doing our kind of work. When I pick up a new one, I always allocate a little bit more for extra ramsticks of the proper size and type. This can often mean having to put two sticks of brand new ram in the parts drawer immediately upon purchaae as the proper use of Double Density (DDR) type sticks means using matched pairs and the mfrs typiocally will do things like install two sticks of 512 to yield 1g - meaning that to properly install 2g, the 512s must be reomoved and replaced with two 1g DDR sticks. Still, it is worth it, especially keeping that live performance issue in mind.
Quote:
As it happens, my clarinet-playing colleague has a new laptop which we use on gigs, so mine is used for preparing songs and individual practice, and will only be used on gigs if something bad happens to his one.
I heartily reommend that you look into raising the ramcount on your older computer before giving up on it. I personally am known for using all sorts of aging XP junk on the live gigs. The only real difference is the loading time of realtracks, which can be gotten around with the use of Freeze tracks. Myself, I have developed the habit of immediately loading the next songfile as soon as I'm done playing he last song, giving more time but making such invisible to my audience. But I don't like to use the Jukebox much on live gigs, preferring the "wait for MIDI input" command to actually start songs.
Quote:
I still think there's a problem with the underlying Fast Generation code which has been revealed, not caused, by my slower machine. If the "Next" button is pressed after a song has started but before the generation is complete (or the equivalent in JukeBox), BIAB doesn't tidy up properly before starting on the next song, and trips itself up.
FWIW, I have developed the habit of not trying to tell BB to do something while it is still doing the first thing *grin*.
--Mac
I'm revisiting this problem, as my clarinettist colleague has been persuaded to use my RealTrack-enhanced versions of our repertoire, synched via Dropbox, as the definitive list, but when he tries to use JukeBox for practice he gets crashes and missing voices in the songs.
He gets very tetchy when this happens, and blames me for interrupting his practice sessions, but I think it's probably happening because he's inclined to set the JukeBox to random, and to click the next button if he's recently practised the song he's offered.
If I can calm him down enough to set RealTracks options as if for a slow computer ("But my computer ISN'T a slow one!"), I'll be able to test this theory.
Incidentally, I've just upped the memory on my elderly laptop to (the maximum) of 2G, but before-and-after stop-watch timings of "Play" and "Generate" have demonstrated absolutely no benefit. As the CPU usage goes up to 100% when generation is taking place, I conclude that the problem is not memory size or disc speed but a lack of raw CPU power.
That's fifty quid that could have bought me a lot of porage!
It would be helpful to have a more elegant way of dealing with the speed of play-back overtaking the process of RealTracks generation, but I suspect that I may be a lone voice here.
Incidentally, Mac, how do you generate the next song without the risk of it's starting to play before you want it to? I can't find a "generate-but-don't-play" button.
Quote:
...Incidentally, Mac, how do you generate the next song without the risk of it's starting to play before you want it to? I can't find a "generate-but-don't-play" button.
One way is to hit the Prefs toolbar button and in the first Prefs Window, take a look on the RH side for "Pause Play until MIDI or Key Received" and check it.
When a songfile is opened, it will then not immediately play, you have to hit either any key on a MIDI keyboard or instrument that is attached to the computer and recognized by BB to start the song, OR hit any key on the computer keyboard to start the song.
--Mac
Quote:
It would be helpful to have a more elegant way of dealing with the speed of play-back overtaking the process of RealTracks generation, but I suspect that I may be a lone voice here.
There is, it's called a fast machine as I've said like 25 times already. Your friend can be as techy as he wants, he doesn't understand how the RT's work and how manipulating audio files in real time requires the latest and greatest to avoid frustrations.
I'm certainly not making fun of anybody or trying to make you feel bad or anything. Money is a big issue to a lot of people in this rotten economy so if someone can't afford it, they can't afford it. If that's the case with you or your friend then just realize you'll just have to live with some limitations until you can get a faster system.
Bob
Bob,
I take your point, but the specification here...
http://www.pgmusic.com/bbwin.requirements.htm...makes no mention of CPU type or clock speed, and only asks for a minimum of 512MB of RAM.
Crashes, segmentation violations and missing instruments on songs don't immediately suggest to the user that his computer isn't powerful enough.
I wonder if a dual progress indicator like there is in a YouTube viewer could be implemented instead of the text indicator saying how many % of the track for each instrument had been generated. If proportion of total played is seen to catch up with proportion of total generated just before things start going wrong, the obvious conclusion can be drawn.
I'm not getting these crashes now that I've disabled fast generation, and I hope my colleague will follow suit.
Mac,
Thanks for the tip - it's just a matter of knowing (and remembering!) where to look...