I want to use an audio file player (AFP, because it can play several tracks simultaneously), and a streaming audio file player (SAFP, because of its markers possibilities), both in the same rackspace.
They must be started/paused and stopped simultaneously. To achieve this I am using 2 pairs of linked widget buttons:
-one button mapped to SAFP Play and another mapped to AFP Play/Stop, both linked via widget link A
-one button mapped to SAFP Stop and another mapped to AFP Playhead Position, both linked via widget link B
This works well and I can start, pause, restart, sop/rewind both players in synchronism. EXCEPT that after a delay, players suddenly stop ! I observed that this delay corresponds to the sum of the durations of both audio files divided by two. Problem happens with any audio file of any length (mp3 and/or wav).
There is no script, no plugin in the rackspace except the two audio players and no marker in the SAFP. So no âexternalâ potential cause of problem. Note that if I remove the link between buttons mapped to Stop, problem disappears (but I cannot stop players in sync ).
Of course, I could replace widget links by scripts (in fact I did this and it works) but that would be a pity not to be able to use this linked widget feature so much it is easy.
Could it be a bug, or am I doing something wrong ?
I will upload the gig tomorrow. It is too late tonight for me.
Just a question as I am new here. Do I put my small gig on a server like Google Drive or Giga and post the link here, or there is a place here where I can upload it ?
To answer your question , I want both players start from the beginning, but also to be paused/restarted, stop together when I press a button or when the end of audio is reached. Except the problem I mention, it works exactly like this. What is strange is this delay before stopping that is half of the sum of both files durations. So audio players are involved. But I made a short script to replace the widegt link on the stop buttons and in this case it works well. So Widget link seems also involved. Also with exactly the same panel but replacing the AFP by an SAFP, it works. So it seems also that the combination SAFP + AFP is involved. Etc⌠I spent a full day at that but could not find any logical answer.
As said, I have workaround but I still though useful to report this strange behaviour.
I reduced it to the minimum. You can use any audio file in players. Mines were 2â54 each (approx) and with these files players stop at 1â29â . It will be different with if files are longer or shorter.
So I just tried the Global Play, including widget/System action. It works well of course.
The only point with this method is that it does not allow to Pause/Restart the players that I can do with my linked widgets as the players allow it.
With the real rackspace, I am using this to be able to play a Backing track in the SAFP, while having the raw lead guitar in AFP together with original recording. This allows me to tune the patch by playing either BT+lead (going through the patch) or the original recording and comparing. Pause is useful as it allows to tune the patch then restart, etc..
I have a workaround with script however, but this strange behaviour when linked widgets are used was deserving some reporting in my opinion.
However, many thanks for your help ! I learnt another thing today. G.P has so many nice features that I discover new ones everyday
I can reproduce the issue, and used a scripted workaround as follows:
Remove widget link B ( which are the widgets that control Playhead Position in the Audio File Player and the Stop parameter in the Streaming Audio File Player
Add a script to the rackspace (The widget for the Stop parameter in the Streaming Audio File Player has handle of StopSAFP and the widget for the Playhead Position in the Audio File Player has a handle of PositionAFP)
Var
StopSAFP : Widget
PositionAFP : Widget
On WidgetValueChanged(newValue : double) from StopSAFP
SetWidgetValue(PositionAFP,0)
End
Using this method you donât have to use Global Play and the players remain in sync.
It is what I had done to make it work as it was the linked Stop buttons that were causing the issue. It is better than Global play as it allows to pause/restart both players, which is what I want. Thanks you for your time Ed and have a nice end of year.
I think I may have figured out what is happening in your original report.
As I recall, the issue was that the audio files stopped halfway into the playback.
In your gig file, you have a widget mapped to the Player Position parameter of the Audio File Player. That button is also widget-linked to the Stop parameter of the Streaming Audio File Player.
The issue ( I think) is that with the widgets linked, relative generic widget integer values between 0 and 127(or between 0 and 1 float values) are interchanged (to stay in sync). I believe that the Stop parameter of the Streaming Audio File Player will engage when that generic widget value reaches its halfway point. So what I think is happening is, the Player Position parameter is calculating the total length of the song, and then scaling the reporting of its widget value based on that calculation. When the position reaches the halfway point of the song, it is reporting that generic widget value via widget link to the other widget (the Stop widget of the SAFP). This activates the Stop widget â because the value is at its halfway point, it now turns on. This in turn stops both players.
I donât think itâs a bug per se, just a result of how the widgets of these two parameters interact when assigned via widget link. Itâs an odd circumstance, but I donât necessarily think anything is broken or wrong.
Just to sweeten a bit this naggy problem, i just fed Suno AI with the following prompt:
âa song in electropop style about running only the half way is enough, refuse to go the full distance, press the stop button at 50%, causing the world to a halt. the song ends with a sudden stopâ
âŚand got this amazing result (which can also be used to have a common audio base, since itâs non commercially AI-generated).
Lyrics:
[Verse 1]
Started the race
Then I liked the view
Halfway there
I was done with âpush throughâ
Saw the signs
âKeep goingâ in red
I hit pause
Let the rest run ahead
[Pre-Chorus]
Every staircase
Doesnât need the top
Every timeline
Doesnât need the drop
If the bar says
âHigherâ every time
I pull the plug
Right before the climb
[Chorus]
Fifty percent stop
Iâm freezing the frame
Half a heartbeat
Still counts the same
If I cut the cord
The circuits all stall
Pressing stop at halfway
Takes the world with my fall
Takes the world
Takes it all
[Verse 2]
People shout
âYouâre wasting your primeâ
But who decided
Whatâs a finished line?
If the wheel spins
It can also stay still
One small click
Overrules their will
[Pre-Chorus]
Every engine
Only runs if I
Feed it seconds
Let the numbers fly
So I hold back
Let the countdown hang
Leave the last half
Dangling on a bang
[Chorus]
Fifty percent stop
Iâm freezing the frame
Half a heartbeat
Still counts the same
If I cut the cord
The circuits all stall
Pressing stop at halfway
Takes the world with my fall
[Chorus]
[Bridge]
[low vocal register] Mid-breath
Mid-word
Mid-kiss
Mid-turn
I choose
This cliff
Half-built
Half-burned
[whispered vocals] One thumb
One touch
No more
[staccato synth hits]
I apologize
For some reason, I was not notified of your last answer in this thread. Also, as this discussion was pursued in another thread, where I was proposed other solutions, I stood with the idea that initial problem had not received explanation. Sorry for that.
I have not understood everything of your last answer above especially this âhalfway pointâ, but what you explain seems logical and corresponds to what is observed. (stop in the middle). So I agree that this is not a bug per se and only an odd coincidence. But I will remember to avoid this kind of construction.
Than you for your time to analyze this.
The thing is: You learned the varying âfloatingâ value of the song position (will climb at very little steps from 0 to 1.0) to a button widget which only knows two states OFF (0) or ON(1.0), while every value below 0.5 means OFF and as soon as the value climbs over 0.5 it will turn to ON (rounding between the two possible states).
So it should be clear that as soon as the song position goes over 0.5, the button will be triggered!
You can try this by linking a knob widget to a button widget (the knob simulates the incoming value of the song position)⌠as soon as you pass the 50% mark, the linked button will change its state!
So, maybe we would need a âend of track reachedâ parameter or something like that, which will be set if⌠well, the track has reached its end. Could also be an optional marker setting within the SAFP â feature request!
).
