Sample/Loop Management

How do you manage your samples and loops?

Ok, this might sound off-topic. But it needs not be. Sonic Pi can do a lot with samples and there’s probably an appropriate way to handle those files.

Been growing increasingly interested in the problem of sample/loop management. Basically, it’s too easy to start accumulating bits and pieces of audio and it quickly becomes difficult to find the ones you need.

Sounds like it’s really not a solved problem. But it’s probably not such a “wicked” problem that there can’t be a fitting solution for it.

The Sonic Pi approach to this problem is probably through the filesystem. Which is why Discourse suggests that this topic is similar to the Print Samplepath thread by @synchron. My exploration is possibly at a more abstract level.

Part of it has to do with different types of samples. One way to think of them is related to length, but not exclusively.

We already discussed wavetables in other threads and they’re extremely short samples, meant to be used as oscillators. That’s the micro-level. At this scale, samples are somewhat similar to synths.
Then you have short one-shot samples meant to be triggered rhythmically, particularly with percussive sounds (:bd_808) or sound effects (:misc_cineboom).
Then, there are soundfonts and other sets of samples meant to work together as an “instrument” (often using recordings from individual notes on the same instrument). @robin.newman has been using those to great effect, though there’s no native support in SP3.
After that, you get into short clips and loops (say, :loop_amen_full), which people often mangle in fun ways.
Above that level, we get into “stems” and tracks, not to mention full pieces of music.

Apart from wavetables, our beloved musicking environment can handle all of these things pretty well. And the included sample library from freesound.org is pretty well-organized.

(In a way, it reminds me of the Celestial Emporium of Benevolent Knowledge. :laughing: )

But how can we manage our own sounds in a way which makes sense in Sonic Pi? Or, conversely, how can Sonic Pi help with the problem of organizing sounds to make them easy to retrieve?

Would be interested in what other people are doing. In fact, part of this interest stems from writing an academic article about “digital musicking” and other forms of “sound appropriation”. So, apologies if it’s too conceptual.

Hi Enk…

‘Me too’… I’ve started adding vocals to the house tracks I’m writing, and recently downloaded
about 4G of stuff from SampleRadar… sorting and using these effectively is going to be a major
pain…

Eli…

1 Like

Hi,
only to explain, why i am trying to get these infos.
I loaded a bunch of sounds from freesound.org to use tham in a radioplay i created with sonicpi. To mention the right sounds with the correct licence, i had to create a list of used sounds.
My organisation was pretty simple…folders. :smiley:

So it looks like that:

takes="D:/path/takes/"
sounds="D:/path/sounds/"
szene=[]
usedSounds=[]

define :take do |name, params| 
  s=sample name, params
  usedSounds[usedSounds.length] = (sample_paths name)[0]
  szene[szene.length]=s
  if params[:ppan] != nil
    control s, pan: params[:ppan], pan_slide: params[:ppan_slide]
  end
  if params[:pamp] != nil
    control s, amp: params[:pamp], amp_slide: params[:pamp_slide]
  end
  sl=0.0
  if params[:sleepoffset] != nil
    sl=params[:sleepoffset]
  end
  puts sl
  puts (sample_duration name, params)
  sleep (sample_duration name, params)+sl
  return s
end


[...]
if playSzene1
  puts "Szene 1"
  with_fx :reverb, room: 0.04 do
  
    in_thread do
      take [sounds, "battle"], pan: 0.5, amp: 0, pamp: 0.3, pamp_slide: 3
    end

    sleep 3
    frankamp=4
    frankpanning=-0.5
    take [takes, "03", "Frank_Bauer"],sleepoffset: -0.3, amp: frankamp, pan: frankpanning
  end
end
1 Like

Hi Alex,

I was grinning because of the Borges-reference (which I encountered in Foucault’s “Order of Samples Things”). I think you did bring up a very crucial issue. As far as I know some DAWs try to do a lot to help users to cope with large sample libraries (browsing capabilities, quick pre’listening’ aso.).

Actually this issue has several aspects of which the technical one is an important but for me not the most crucial. I am thinking of the general dilemma that on the one hand you wish to have as much options as possible but on the other hand the bigger the choice the more you will suffer from something like a decision paralysis. Well, at least I do or did.

I have some shortcuts in my ~/.sonic-pi: Right now those are:

  • beats # drum loops
  • hihats # hihat loops
  • lcc # live coding challenge samples
  • mb # self recorded stuff
  • clap # single shot: claps
  • kick # sinlge shot: kicks
  • sound # mhmm… admospheres, mostly loops
  • tambourine # single shot: tambourines

I do reference samples usually like this:

sample kick, "theDeepOne"

which assumes that I somehow know something about what the filename contains. I used to use also something like

sample beats + "hiphop", 1

which is quite mighty because you can easily reference subfolders. But this does not solve the more general problem that the more samples I have stored for use within Sonic Pi, the more I have to listen to, the longer it’ll take to choose one of them without being entirely sure if there is not some even better sample sleeping on my harddrive. So unless I have a specific sound in mind or want to recreate something I kind of try to delegate the choice of material I am working with to chance or alternatively try to keep a very small collection of samples I am actually using. So - at least for now - I have given up to systematically collect and categorize samples for working within Sonic Pi.

The folder lcc contains a collection of samples I grabbed from the SOS-magazine (famous drum loops, synth sounds aso.). I prepared loops from that and defined a live coding challenge for myself: Take two or three loops from that folder and do something with it (to have some aid the filename e. g. contains a key if there is one or the string ‘nokey’ which indicates e. g. a drum loop or some non-tonal sound). (I wish I’d more consequently work with this concept and accept my own challenge - but sometimes I do…).

The rest of the folders contain samples I especially like or would like to work with some day.

The general idea for me is: I rarely create music with Sonic Pi with a fixed idea in my head. Especially the idea of live coding for me contains a kind of obligation to work with what is at hand. That also relieves me from difficult and potentially endless choice which bassdrum or other sound would be the best in some case. Usually this leads to decision paralysis in my case.
Hope I was not drifting to much with this posting.

3 Likes

Sounds good! And it’s a good point about licensing. Been thinking about this quite a bit in terms of sample libraries. They sometimes credit artists directly, but rarely in the case of the performers themselves. And it’s really hard to keep track of that data, unless you maintain a database of some kind. A flat-file database (with the filesystem) makes a lot of sense, in this case.

While it should really be pleasurable, not painful!
At this point, my sample collection is probably hundreds of GBs. Just the free packs from Noiiz were 15GB. Eventually registered for a full account (until tomorrow, it’s 100$/year). Also got stuff from Splice and Loopcloud and Ghosthack and Samples from Mars…
It’s really becoming a needle in the haystack issue. Especially since a whole lot of these samples are pretty much the same. For someone who’s not that enamoured with the TR-808 and could do without “4x4 loops” (straight 16ths in 4/4 beat), it’s tough to find my way around.

At the same time, there’s so much we can do with just about any samples.
My most recent “discovery” is about extracting the melodic information from a solo voice or woodwind into MIDI files (using Waves Tune) and doubling that with some synths. Really nice effect. Been doing that in a DAW (with Reaktor synths, mostly). But it should work quite well in Sonic Pi as well, using MIDI-handling techniques perfected by @robin.newman

No drifting at all, @Martin!
The paralysis you describe is a big part of the issue. Like fiddling with technical problems, auditioning hundreds of kick samples isn’t usually my idea of musicking fun. It can be ok on occasion, but it requires a specific kind of concentration. And it’s not necessarily that inspiring, to me. Actually, the same thing happens with coding, to be honest. It can be hugely pleasurable to get into a coding mind with Sonic Pi. But there are many moments in my life during which other approaches to musicking are more viscerally fun. It’s all a matter of moment.

In my case, the choice paralysis has been leading me to experiment with diverse methods. Still accumulating quite a few samples from diverse libraries. Will hopefully get around to organizing some of them in a meaningful way. Got rather hopeful this morning as Noiiz announced it’d allow us to upload our own samples. It’s what pushed me to register for a full account. It’s quite limited (5MB per sample for a maximum of 5GB, not even giving us access to tagging, yet). But it filled me with hope.

While DAWs and plugins do have the features you describe and then some (time- and/or pitch-stretching, for instance), they still leave a lot to be desired. In a way, you have to fit the DAW, including the way it arranges a “project”. With practice, people surely get very efficient. And it’s probably easier for those who enjoy quantizing everything and adding a bit of swing later. But it’s pretty difficult to get into this.
The iOS apps created by Ampify (Novation/Focusrite) are rather interesting in the way they push for immediate playfulness and allow to organize things further on. Much of it is about selling soundpacks, but these samples really do go very well together, in all sorts of ways.
Would probably enjoy creating something similar for use in Sonic Pi. A set of, say, 20 loops which go really well together, no matter how they’re mixed and matched. Could then use a grid à la Launchpad (via TouchOSC or even my Lightpad Block) to trigger those. But it’d also allow for melodic playing of some onboard synths.

Thanks for humouring me, @synchron, @Eli, and @Martin! You’ve all given me more food for thought.

Awww heck… And I was thinking I was gettin
pretty good with:

with_fx :echo do
sample lib2,1,amp: 0.2
s = sample_duration lib2,1
end

:slight_smile:

Eli…

STOP THE PRESS: Just now discovered with_fx :octaver …

Herbie Hancock rides again !!! :slight_smile:

1 Like

Thanks for your excellent question!

Currently, there’s no GUI-supported way of managing/exploring your recorded sounds (wav/flac/aiff etc). This is something I’d like to address in the future, but would also love to know the kinds of things people are looking for.

Personally, I currently rely heavily on adding meta information in the filenames of the audio files (typically this is already the case with all the sample packs I’ve purchased). For example, I have many samples with names such as 120_Cm_Arp_SP_06.wav. I can take advantage of names like this using the filter functionality in sample as documented in Section 3.7 of the built-in tutorial.

One thing I’m looking to do is to add some automated metadata detection (such as BPM/pitch/energy etc) which could be accessed via a more high-level filter API than just filename text.

Happy to consider people’s ideas at this stage though. What are you missing, what might fix the gap?

1 Like

Hi,

I think a major help would be a completion function such as:

You have e. g. in you .sonic-pi:

define :my_samples do
  my_samples = "/home/me/sonicpi-projects/my_samples"
end

Once you type in sample my_samples you will get a popup just like the one you’ll get once you type sample only this time you get a view of all *.wav and *.aiff-files in this directory. This would make the choice of samples for defined and prepared directories quite easy.

I am well aware that to implement such a feature there must go some more thoughts in it to match or gracefully degrade cases I have not thought of resp. to create a generative function which behaves constantly in all cases. Just some thoughts and a quick sketch…

Martin

Interesting idea :slight_smile:

I can’t ever see that working with the current implementation as it would require some sort of ability to partially evaluate code (i.e. to call the fn my_samples when it is used as an argument to sample).

However, I can imagine something similar that used a more declarative style such as:

sample_pack :my_samples, "/home/me/sonicpi-projects/my_samples"

However, I also have this wild ambitious idea to have a central repo of assets - or at least crypto hashes of assets and paths to their locations which could then be used and passed around. That way you could create your own sample groups/folders which don’t necessarily need to map to the filesystem.

3 Likes

Using sample_pack is in the long run a much better idea then to set up a custom function the way I proposed; it is easier and more transparent. My main concern was/is that if you somehow organise your samples by using information in the filenames it would be great to have some sort of listing to avoid the need to have everything stored in your brain.

As to your second thought: It seems quite tempting to me to make such a sample collection virtually independant from the structure of ones file system. Do you care to sketch out of how this would be usable and look like from the users point of view?

I don’t really have any detailed idea from a user-perspective yet. I’ve just been thinking about the technical feasibility of such a design.

I think the first stage would be to start implementing the foundation parts, and then start using myself at a very low-level (i.e. not very user-friendly) for a while to figure out what exactly it is and how it can be used. Once I’ve understood that a bit better, I’ll be in more of a position to consider the user-interface :slight_smile:

1 Like

I like this approach because I am sure, it’ll need a while until you can find out how to implement a consistant and easy-to-use feature.

Having said that, I’d really like the idea of a completion function for non-inbuild samples (given a folder path). Here is a mockup:

3 Likes

Part of the reason the samplepack idea is interesting is that it could allow musickers to share useful things without having to know too much about Sonic Pi itself.

The idea could then be, someone could record things directly in Sonic Pi, with a special folder structure and filename system to provide valuable data about those sounds. From field recordings to Sonic Pi compositions, we would then have a flat file database of cool sounds. With some sort of central repository (maybe through Freesound or other system for CC-licensed sound files), she could then share her sounds with other Sonic Pi users for further use.

Something which might be worth exploring is existing file formats. Been downloading samplepacks from a variety of vendors and they tend to come in several formats having to do with (commercial) software, usually a DAW: Ableton Live, Native Instrumend ts Kontakt, Propellerheads REX2, Apple Logic Pro X EXS24, Apple Loops, etc. Typically, the downloads also contain the raw samples, but there’s added value in having them packaged in a format used by the DAW. For “soundfonts”, the two file formats commonly used are more agnostic (SF2 and SFZ), and there’s Free Software which can use them. Surely, some people have come up with non-proprietary formats for the other types of soundfiles. These might provide some of the added value found in the commercial soundpacks. In fact, there must be a format out there which attaches useful metadata to these files, like ID3 tags on MP3 files. Things like performer, recording location, equipment used, warp/loop points, tuning system, description, etc. Unpacking a samplepack containing such metadata could create a useful structure to reuse the samples contained.

Sounds to me like samplepacks have become a significant trend in the commercial world. A few iOS apps (especially British ones, for some reason) use a simple “freemium” model: the app itself is free, soundpacks are IAP (“in-app purchases”), anywhere from 1$ to 10$. The whole notion that those packs are “consumables” interests me in terms of the commodification of music. Especially since the packs are like components of a piece of music which can then be remixed, mashed up, mangled, reappropriated, reinterpreted, etc. In some (most) cases, they can even be used in production of music to be sold. Very cool stuff from an academic perspective.

But back in the Free/Libre Open Source/Content/Access/Educational Resources world of Sonic Pi, instead of a “business model”, it’s an opportunity to co-create through shared resources. Freesound itself is fascinating from that perspective. Some of it can be attribution, though we don’t yet have any consistent mechanism to attribute the authorship of the samples we use. It’s also a cool way to discover and appropriate others’ sounds: make them our own and make them appropriate to our contexts.

Not completely sure what the easiest implementation in Sonic Pi would feel like, but it could all lead to something very cool in terms of peer-learning.

1 Like

automated metadata detection…
GitHub - ndac-todoroki/elixir-id3: ID3v1 reader / ID3v2 read-writer for Elixir, using Rust NIF

Hello! Is this useful?

Also related
(for fellow community members with insatiable appetites for information understanding) LiveBeats: Building a social music app with Phoenix LiveView · The Fly Blog

I don’t think so, no. The idea, here, is less about reading data in MP3 files than creating a cataloging system for soundfiles (of any type). In other words, it’s about the metadata to include in tags like these instead of reading those tags. (There have been multiple ways to read tags since the WinAmp days…)