Can you do a test and use GP Script to select the track and then hear if the BUZZ occurs?
Good point, sorry!
Your level of participation and frequent high quality of answers makes it easy to slip into thinking you are part of the Firm.
1 Like
You mean like a widget button that fires a script to make the selection?
Try this, you have to load your Audio Files.
When this is working, remove the mapping of the global Widget to the Audio File Player and create Song part actions and test again.
Song.gig (42.0 KB)
Thanks kindly for the setup.
Following your script, adding 11 songs in the SAFP and creating 11 songs in the setlist, everything operated fine. This was not unexpected to me. If the System Action → SAFP path was broken for simple, general cases it would have been reported and fixed long ago.
The cause lies somewhere in the in the intersection of System Action → SAFP with my larger configuration (gig). My own insight falls short of having a good idea about where this might be.
Undertaking process-of-elimination with no good idea of where to start or what path to take invites possibly days or weeks of effort. Without insight, or tools, or ideally both, it’s not an attractive prospect.
So with my gig file und using actions there is no issue?
So with my gig file und using actions there is no issue?
That’s right.
So you should remove rackspace by rackspace until the issue disappears.
OK, I believe i have figured out what was going on. I will describe it so others can avoid it.
Background -
First, tracks in the SAFP needed marker actions to select song parts, in order to change synth sounds with changes from verse to chorus, etc. while the backing plays. This was essential to the musical/sonic presentation. Non-negotiable! So, marker actions were placed in the SAFP tracks to select the corresponding song parts, including a marker action at/near the start of each .wav file to select the first song part of the corresponding song.
Second, as a matter of convenience (negotiable …), it was my goal to be able to be able to select any song in the Setlist and have the SAFP set itself to the matching track. The method attempted for this was to place a system action on the first song part for each song which would make the track selection in the SAFP. This itself worked, but trouble lurks, because
Once I actually started playback of a track in the SAFP, the first marker action would select the first song part -
and then the system action in the song part would (re)select the track in the SAFP, and since playback is now running,
the SAFP would (re)select the song part,
and the song part would (re)select the SAFP track,
etc.
IOW, a selection loop Result: BUZZ and lockup.
Solution: Remove the system action from the song part. This breaks the loop. This accounts for the problem being observed when system action was present and executed, and problem not being observed when system action was un-present or un-executed.
To reestablish bi-directional selection, I put script code to select the desired SAFP track in the GRS On Song() callback ( not the On Songpart() callback! ) .
Things now seem stable here (at least in this respect). Yay!
Comments -
This had nothing to do with my overall size or complexity of gig file. Extensive process of elimination (tearing down the gig to simplify it) would have all been time wasted. Solving it did not require reproducing it, it required thought/analysis.
I originally attached the “offending” system action to the (first) song part entirely because it is not (currently) possible to attach the action to a song. If that had been possible, that is what I would have done and there never would have been a loop.
I don’t know if there is some reasonable-to-implement technical means by which such a loop situation could be detected/prevented. But if there is, it would be a good enhancement to add to GP at some point.
Offhand, being able to attach system actions to a Song itself (rather than only to Song Parts) seems desirable.
Caveat -
Though the problem seems solved (so far anyway), my analysis/diagnosis may still not be correct. But for now, I’ll take it!
Cheers!
The problem is, even if one tried to prevent that, there are many other ways that it could happen anyway. For example, songpart 1 goes to marker 1. Marker 1 has an action that says go to songpart2. Songpart 2 has an action that says go to marker2 but marker2 is (for some reason) just before marker1
The motto, at least for now is, “With great power comes great responsibility” 
As for actions associated with songs, that was actually a great suggestion and will be implemented in a future version.
2 Likes