Streaming Sampler Player beta ready for testing

Announcements
81

ty much for explaining all that! really appreciate it and it’s helping me better come to terms w the limitations/best practices for this whole 6x template.

personal take: i think it’s good w it’s current behavior, gives more freedom? although w that comes responsibility/ the possibility to run into the issue im hitting but im realizing now, that really just need to wait a bit after running, let the ram fill up.

im finding that the screen timeout could maybe be a useful indicator? i need to do more real world tests with that idea though

2 cents: maybe more granularity might not be a bad thing here?

i wonder if there’s any way to grant buffering precedence to tsps that are first played after the patch is run? so after hitting run, then hitting play on say tsp 1, the others would then buffer slower and allow tsp 1 to buffer faster/not underflow. or making the first tsp in the patch load fastest, 2nd tsp (but module id#?) load a little less fast to allow tsp 1 to load more etcetc? maybe all that’s not possible/too complex (or maybe only doable in a single 6x tsp type module), or too risky or edge case.

i have 2 on order. and that’s awesome and great to hear that the load times are sped up quite bit with those! i’m hoping they’ll get in soon so i can start experimenting with them.

82

I actually tried implementing this just now. You might want to try it, as it solves the problem of knowing when the best time to start playback. You can turn the knob to start playback right when you start playing the patch, and it will automatically play when it’s loaded enough. Set a lower buffer threshold on the two TSPs you want to play first, and then try to play them immediately when you load the patch. They’ll start automatically at the optimal time. Once they’ve played through once, they’ll be fully buffered so it ends up being the same as 80%, it just starts audio a lot earlier and takes the guesswork out.

In terms of other users coming to the module for the first time, it might not be obvious you need to wait to start playback, and if you don’t know that then it ends up acting weird and seems broken. So I feel like we need something there to safeguard bypassing the buffering system.

I could make it an option, something like Minimum Buffer Threshold vs. Target Buffer Threshold. So it would refuse to playback until it’s buffered the Minimum, and then it’ll keep buffering until it hits the target.

Not sure what you mean by the “screen timeout”?

Yeah, 20/40/60/80 is pretty coarse.

Not easily… each module is independent. The easiest way would be a 6x player.
If we had a multitrack player, that played wav files with 12 channels (6x stereo), it might be more efficient.
The tracks would be locked together in time, i.e. they would all start playing at the same time and all tracks would need to be the same length of course. So not exactly the same control in terms of timing/rhythmic placement that you have with 6 independent players. But it might offer advantages in terms of SD Card speed since all the data would be together on the disk, not spread out over 6 files.
I’d have to try it to see if it really does improve SD Card performance.

83

sorry i should have typed screensaver.. the timeout amount being the “guide”, so when the screen goes dark after a minute, its safe to start playing the tsps

i’ll give it a shot. seems like it would make the thing more new user proof.

interesting. definitely not as generative or aleatoric as asynchronous loops, but probably still a lot of possibilities as far as timings on when certain layers are allowed to wax/wane dynamically. i know this is just a theoretical module, but if it ever gets off the idea table, happy to run it through the paces.

84

Here’s TSP-19. I fixed the crash on load, and also made it so playback won’t start until the buffer reaches the threshold. So you probably will want to drop down to 20% for all (or at least some) of the modules in your example patches, or else it takes a while to hear sound.

85

awesome will try putting the first 2 tsps at a lower thresh. one thing i’m curious about: if there’s a way to make the tsp more obvious when the threshold has been met (so a trigger play will cause instant playback (versus waiting arbitrary length for the orange button to turn green)).. so at a quick glance during a live performance i can look at the screen and know which tsps are good to go. play button flashing green? orange bar flashing? would be most useful for knowing its safe to trigger play, that the sound will occur instant at that point. like if there’s a preexisting beat or rhythm already going.. hopefully that makes sense

edit:or perhaps there’s some other easy way to tell that i’m not seeing?

86

When a patch like this with several big samples loads, the red lights will go solid red at first. When the threshold is met, the red light will go off. This means the module is ready to play.

Or, if you trigger play while the red light is still solid, then the Play button will turn orange/yellow to indicate that it’ll start playing automatically once it has enough buffered. Then it’ll automatically turn green when it starts playing.

One thing I could do easily is have the play button turn a certain color if the buffer is not at the threshold yet. If you triggered play then it’ll be orangish-yellow, but if you haven’t triggered play then it stays grey. I could change the grey in that situation to something else if that helps.

87

ah ok i never correlated that solid red right after triggering play with buffer threshold filling, probably because we didn’t have the main button turn orange before.

but also the read light turns solid red again(usually) after hitting play (after it was grey): that can be a little bit confusing visually, but i think one could get used to it

i’m curious if it makes sense to also have a 100% to get the entire sample to load into ram first? might allow the most safe, non-undeflow behavior.

also i’m trying a staggered threshold approach(20%,20,50,75,80,80), but it doesn’t seem to be any more effective. even if i just turn on tsp 1 right when it’s ready to go (after initial red light turns grey), while the others are still buffering into ram, 1 will often crap out.

really wish there was a way to make tsp 1 load first fully into ram(or at least mostly), then tsp 2, then 3.. as that would make playing things in order safer, more effective. it seems when all 6 are trying to buffer/read from the card at the exact same time, that’s when the card tends to bog down, become less effective. again, we’ll see with the delkin.

88

I’ll see if I can come up with another color to indicate this state. Or maybe use the waveform color too…

Yeah good idea.

Oh well. I had good results doing that. It’s strange how different the card you’re using works compared to all the ones I’ve tried here. Hopefully testing with the Delkin card will work for you.

A 6x module would be able to stagger like that. But with individual modules, hmm… I could make it so they fill their buffers to the threshold when the patch is first loaded, one module at a time, with no overlapping. But the entire GUI would be frozen so you couldn’t start playback until they’re all done. That’s essentially how the Canard and Sicko samplers work, though with the TSP you could have them just load 20% of the sample before you start playback.

Since I’m running the same files and patches as you but am having much better results (very rarely do I ever see underruns, never see red waveforms), I’m hoping it’s just a matter of the card not being fast enough to stream 6x files at once.

89

love the waveform color idea, would be big and obvious/much harder to miss than the little read light.

it feels pretty random how the cards behave. since i have 2 mms, and load the same yml on both, and hit run at the exact same time on both i notice big discrepancies. sometimes on the left mm, tsp 3 finish prebuffering first, whereas on the right mm tsp 5 is the first to prebuffer. sometimes all but 1 or 2 tsps will prebuffer, and the remaining will take like 3 minutes to finish (even though those samples are smaller than the others), as if the card is just simply choked and going really slow for whatever reason. and then i can power cycle the rig, load/run the exact same patches on both mms again, and get completely different result.

i suppose that would defeat the purpose. at least with tsps, we can watch them load and have an idea when they’re ready. it’s just quite random, as mentioned previously, which tsps will be loaded/ready first. of course i know file size/length of the .wav has a lot to do with that

im assuming you’re using the 80% thresh ones i sent you. i am noticing with those, a lot more stability than with the staggered threshold ymls. but there are still some cases, like mentioned above, where it seems some tsps just get ‘stuck’ and take forever to finish loading the sample fully into ram. maybe these sdcs are faulty i have no idea.

i will try another staggering: 40%,4,6,6,8,8 next to see if that’s any better.. (and then maybe 60%,6,6,8,8,8) essentially my goal is to be able to load/run a yml and be able to play tsps 1,2,3 much quicker (without having to neuter the length of samples going into tsps 1,2,3 to compensate). fingers crossed on these delkins!

90

also i’m curious what your settings are- i’m at 48/512. not sure if that makes a difference

and, is there a way to clear a sample from one of the tsps directly on the mm (without having to edit the yml)? if not no biggy..

91

I’ve been at 48/512 mostly. I was running into more errors with the larger block size so I kept testing with it at that.

That could be useful. I could add a menu item like “Unload Sample” right above “Load Sample…”

I played with this, but realized that when the sample is pre-buffering, the waveform is just a horizontal line. So changing its color is not very obvious. I might work with the bar color… or maybe a different button color.

92

so far these delkins are definitely a bit faster, not by a large margin but it’s still certainly noticeably more stable/useful (using a threshold variant of 60%,6,6,8,8,8, but might try lower again with these new cards). i guess if need be, if i’m really desperate for filling space between while the next patch is waiting to load the samples, there’s always the option to have some extra material ready to play from an old iphone or looper pedal or something (though if im being honest, would much just rather use the mm and nothing more).

in terms of getting these tsps to load in order so tsps 1 and 2 could be preloading faster and ready to play first, then say the next 2 preloading 2nd, then the last 2 3rd, what about the idea of having an option(in 5 second increments?) that would delay the start of the tsps preloading? which could be overridden by triggering play. not sure if that makes sense or would make a difference in helping the 1st tsps that actually need to be played up front, to be ready in better order, but im curious of your thoughts there.

also would be cool to have the option to turn off the safe guard that causes the play button to be orange if play is triggered prematurely while a tsp is prebuffering. you mentioned before: “make it an option, something like Minimum Buffer Threshold vs. Target Buffer Threshold. So it would refuse to playback until it’s buffered the Minimum, and then it’ll keep buffering until it hits the target.” - curious if that’s what you meant there? anyway, id love to try and do more tests without it at least with these delkins, if possible

also ive been noticing that sometimes the safeguard works, and other times it doesn’t seem to be or i just am not understanding something. sometimes i can trigger play when the buffer is only at 10-15% and it’ll start playing/turn green (which is nice!) other times, the button will turn orange and i have to wait for a while for the buffer to fill after that.

maybe blue? or the background behind the wave form could turn a certain color or flash between black/green? i am getting used to following the small red light although it’s still quite small and easy to miss especially when there are 6 tsps in a row.

edit: also tsp19 is feeling VERY stable in terms of going through all these ymls quickly with no crashes and no need for turning anything off beforehand. REALLY appreciating that!!

93

Great! That was the goal of all those last rounds of fixes (the concurrency bugs). It’s been very stable for me as well.

Yeah, something like this would help fill the gap after a patch loads. The fastest way to get from a wav file on disk to audio output is to load just one file at a time. Maybe the most simple thing is we could have an option to enable/disable immediate pre-buffering when the patch loads. So you would enable it for tsps 1 and 2, and also set their thresholds very low (so they are ready to play quickly). As soon as the patch loads, trigger their playback and audio will start coming quickly. Then for the other modules you disable automatic pre-buffering, so they just sit idle when the patch loads (no disk access). Once the first group of modules are making sound, you trigger the second group (or maybe trigger them one a time as you need them), and they’ll start pre-buffering and then play.
A timed delay would also work, it could be 0, 1, 2, 3, 4, 5, infinity seconds or something. But to start I might just play with having it on or off only.
My idea about Minimum/Target threshold is probably overly complicated… your idea to have a timed delay in seconds is basically the same thing, and a lot easier to grasp.

I can see the reason for wanting to disable that, but there’s a higher risk of underflows and long SD Card stalls. I don’t know… Maybe it could be an advanced feature a user can enable if they know the risk. It would need to be worded in a way that anyone who enables this mode would immediately know to disable it if they start getting buffer underruns. I’m hoping the timed delay or disabling automatic pre-buffering would do it, that’s a bit more elegant of a solution and doesn’t carry the risk of a card stall making all 6 modules go on the blink.

I’ve been trying to track this down, too. Sometimes I can get it to play before the buffer is at the threshold if I hit play at the right moment while it’s loading.

Re: colors, I started playing with setting the orange bar different colors. That works pretty well, and makes sense since the bar shows what’s been loaded and that’s what we’re waiting for anyways.
Orange/yellow = loading (can’t play), greenish/teal = ready to play, and some other color for fully buffered (also ready to play).

Also – heads up-- I’m also working on making the Buffer Threshold setting to be continuous from 0 - 100%. So once I release that version, all patches made with the old version will need the Threshold value changed (should be a easy to change in the text file).

94

i realize this is a more advanced/nitch thing, certainly would want ‘prebuffer play guard’ enabled/on by default to suite a majority of the use cases. but i feel having that higher level control would really be useful in performance cases where you really just know how the tsps are behaving with the sdc/samples you’re using. i’m finding its easy to intuit this "safe timing to start playing’ as im sort of speed running through all these ymls. and since the current prebuffer play guard isn’t working 100% - the fact that it’s not working (and based on my experiences with pre tsp19 where we didn’t have that guard) all that is actually really helping inform me that there’s an obvious ‘safe zone’ that i can intuit just by looking at that orange bar and how far along it is. and it’s even faster/safer i’m noticing, with these delkins - to manually start playing when the orange load bar gets to a certain length. having that orange visual there is a HUGE tool btw in learning/knowing this safe zone. so ty again for adding that!!

from observing the behavior of these ymls and the sdc’s a ton now, i believe the most ideal scenario of ‘options/settings’ to best orchestrate all 6 (and i think this too would work well for even much higher numbers of tsps than 6) to squeeze out the best performance situation - i would set their thresholds to 100%(so it just constantly loads instead of stopping at a certain %), delay the preload start time between each tsp by 5-10 seconds, and have prebuffer play guard off because i personally know now having messed with these ymls a lot with the current settings, that when that orange bar hits between 10-20% full, i can start running them with no problem while the others are still loading and not receive any underflows. i know i could set every one to 20% at that point, but i do just want the tsps to fully load, and not stop at 20%. the sooner they all are loaded into ram the better, but of course the order matters too, we don’t want the last tsps that i need to play, to load first (hence the usefulness of seconds delay).

i’d love to be able to try that scenario out, but i also understand we don’t want to over convolute the tsp with too many crazy options (or bog you down with all that code as well!)

even if we don’t have the preload delay stuff in there to help orchestrate preloading, i still think being able to disable that play guard would really be huge. but if not, but im certainly down to try just the preload on/off option in there as well and see how that is to start.

no problem! im using notepad++ which allow for fairly painless batch find/replace of entire sections within a folder.

95

Right, and that’s the idea behind the Buffer Threshold setting: if you know your card and patch well enough to know the TSPs are safe to play when the bar is at some percentage, then you would set the Threshold to that percentage. Then you don’t have to do guesswork based on the size of the bar, you can rely on it to automatically change color and start playing.

I think that’s the piece that’s missing from the current setup: if Threshold is at 20%, it stops pre-loading at 20% until you start playback. Then it tries to keep 20% ahead until it’s fully buffered. But there’s no way to have it keep buffering beyond 20% unless you start playing.

And this is probably the part I’m not understanding: why is it that you want to have it not stop at 20%? If you know it’s safe to play once it hits 20%, why do you want it to keep reading farther ahead than that? Is it just that when all the samples are fully buffered, the GUI is more responsive? Or it is the extra re-assurance that no SD Card failures could stop the patch since everything’s in RAM?

I could see an easy solution to this is to add a “Pre-buffer as much as possible” option. So with this enabled, you could set the Threshold to 20% (or 0% if you want the fully manual override) so that you can start playback early. But it would keep buffering ahead until it fills the buffer.

Yeah, staggering the initial loading would be helpful. I think I can add this easily

96

it’s really mainly this factor

yeah that makes sense! i think that could be really great, especially paired with the prebuffer start delay option

awesome i really look forward to testing any of this out!!

97

I get it, yeah. Those early versions were pretty rough and unstable, and you experienced lots of crashes, so I get that! I’m hoping now that we have most/all of the stability bugs worked out that it won’t be as big of a deal to get to 100% buffered. At least, that’s my goal – to make it possible to stream from more than 6 TSPs on a fast card without any risk of crashing or big underflows.

I made TSP-20 which adds in Startup Delay (variable 0 - 30 seconds). This makes a huge difference, thank you for the idea!
I also added Buffer Target which can be “Fill to threshold” or “Fill completely”.
The Threshold setting is now continuous from 0 to 100%. So at 0% there is no mandatory pre-buffering, you are on your own to time it right.

I’ve been testing it with the large-file patches you sent me, with:

  • TSP 1 set to 10% threshold. TSPs 2-6 set to 20% threshold
  • TSP 1 and 2 set to no startup delay. TSP 3-6 are 10, 15, 20, 25 sec

With this setup I get audio from TSP 1 and 2 almost immediately (2 seconds?) even on the old slower card. Then TSPs 3-6 are staggered so we get sound from them a few seconds after their startup delay. Since the delays and thresholds are all handled by the TSPs, I just wiggle all the playback knobs at any point after loading and they all start playing automatically at the right time.

I’ve tried it with all TSPs set to Fill To Threshold, and with all set to Fill Completely. I’m not noticing a big difference either way.

In general, I would encourage you to set the thresholds lower when using large files. E.g. 20% threshold on a 50second sample is 10 seconds of audio, which is a large enough buffer for any kind of SD card glitch/stall (I would hope!). For smaller files, a larger %age is needed of course.

Some notes on using a text editor to convert old patches:

  • param_id: 4 is still Threshold. It’s now a floating point number 0 to 1 directly representing %. So 20% is 0.2
  • param_id: 6 is the Buffer Target. 0=Fill to threshold, 1=Fill completely
  • param_id: 7 is Startup Delay. It’s in steps of 1/12:
    • The delay choices are 0, 1, 2, 3, 4, 5, 8, 10, 12, 15, 20, 25, 30
    • 0 = no delay, 0.0833 = 1 sec, … 0.41666 = 5 sec, 0.5 = 8 sec, 0.5833 = 10sec, 0.666667 = 12sec, 0.75 = 15sec, … , 1.0 = 30sec

Edit: oh yes, and the colors of the bar changed:

  • Grey: buffering, not able to play yet
  • Blue: buffered to threshold, ready to play
  • Green: sample file is fully buffered

When the module is pausing for the startup delay, the waveform line is dark blue instead of teal.

98

ok wow that was fast TY!!! playing with it now and it’s quite A LOT more flexible, the delay is really helping things! and these new colors are way clearer.

and ty for the param_id notes, extremely useful.

just played through 16 of the ymls (with the larger files i sent you) and i’m able to really move through them quite snappily at this point with the delkins. going to keep messing around with it, but it’s feeling so far super solid.

btw, im curious if there was any future plan to add any sort of ramp or click free type behavior on play/stop/pause? would love to utilize the play/pause mode but its currently very noisy with a lot of the sounds i’m working with. but as it currently is, still really awesome! i look forward to rocking this out during the next few live performances! :smiley:

99

one thing i’m noticing is that, when ‘buffer target’ is set to ‘fill completely’, and the thresh is set to 0, the buffer will stop filling if i first start playing the tsp, and then stop playing. the blue bar just sits there not growing. is that normal behavior? i would imagine that with ‘fill completely’, it would just keep trying to fill to the max regardless. but also perhaps im doing something wrong with the settings.

normally i try wait for the tsps to load to a point where it doesn’t matter but there are times where i accidently jostle or nudge one of the smaller knobs that send the triggers aright fter running the patch, and they tend to send their current value at that point so this accidentally sometimes will send a play trigger, that then stops the prebuffering.

100

I wasn’t sure how to handle that case… With “fill completely”, it only fills when it’s pre-buffering (immediately after loading a sample) or if it’s playing. I see your point that if you start playing accidentally, pausing the audio will stop the “fill completely” from happening. I could make it keep filling no matter what.

1 Like