Alternatively, I would be grateful for any tips and tricks regarding how to use sample effectively in a live coding session, and I would be very interested if anyone have an interesting sample starter pack to share or recommend.
Since I’m around, I’ll chime in
He is storing references to his own sample paths in code. (I think this was by using functions to return those paths - correct me otherwise @samaaron!). So in this case, ebit_bass and bass_atmos return the paths to the bass samples in the ebit pack, and atmos samples in the bass pack respectively.
I do a similar thing, as no doubt others do also. Since functions stay in memory and are persistent across buffers, it can be useful for example to run some functions that define the paths to custom samples when Sonic Pi starts up - using the init.rb file in the .sonic-pi config folder.
How you could construct such functions is a matter of preference really - I have a bunch of hashes that map folder paths of each sample pack’s categories to specific keys, nested inside a larger hash that maps the root folder of each pack to another key. Then I use these to make new functions pointing to each path of the sample pack categories, which I then load on Sonic Pi startup
The above is one strategy that is useful to some degree. It still requires you to know the sample pack and category keys, (or to perhaps have a further function that prints out all these keys). I’m sure there are other tricks that might be useful, that may or may not require either extra support code in your composition, or code added to Sonic Pi itself.
Right. Was (and still am) mostly interested in how people organize their sample collections. Sounds to me like it isn’t a “solved problem”, generally. SPi can help.
And the way SPi handles sample packs affords some explanation. No wonder it’s described in the tutorial as an advanced topic (section 3.7 in version 3.3.0). Haven’t tried explaining it to the proverbial 10 year-old. Filesystem stuff tends to be cumbersome to explain. Especially with regex.