Allow tidal to query superdirt for a list of samples / synths / effects?

[yaxu]

We now have the rms capability, could we add a way for tidal to ask which samples / synths are available? Maybe effects too?

[bgold-cosmos]

FWIW, on the SuperDirt end of things you can get samples, effects, and global effects with something like

// sample information
~dirt.postSampleInfo
// for a printout, or to get an array
~dirt.soundLibrary.bufferEvents.keys.asArray.sort

// registered "effects" should be in this list
~dirt.modules.collect({|x| x.name})

// global effects show up here
~dirt.orbits[0].globalEffects.collect({|x| x.name})

I expected

~dirt.soundLibrary.synthEvents.keys.asArray.sort

to list all the "synth" instruments but they don't seem to show up here, maybe I'm not registering them properly? Usually I just make a SynthDef, and I think SuperDirt doesn't necessarily keep a lookup of every SynthDef since many of them may have nothing to do with SuperDIrt.

In the past to try to find all the "synths" I've defined I use this, but I think it may still grab things that are unrelated to SuperDirt

( // this bit should show all "instrument" synthDefs
var keys = SynthDescLib.global.synthDescs.keys;
keys = keys.select( {|k,i|
	var notSys = "system_".matchRegexp(k.asString).not;
	var notDirt = "dirt_".matchRegexp(k.asString).not;
	notSys && notDirt;
});
keys.asList.sort.do{|x| postln(x)};
nil;
)

[telephon]

Yes, defining a synth event is optional, you just do it when you need specific parameters or transformations of parameters. The rest is just normal SynthDefs. As you show, you can easily get a list of all SynthDefs (SynthDescLib.default.synthDescs), but these are also others that won't work properly with tidal.

So some explicit bookkeeping is necessary for this.

[yaxu]

This is related to tidalcycles/Dirt-Samples#15 then. A general way of cataloguing samples and synths metadata, including #122 .

[yaxu]

I'm talking with @lwlsn about this sort of thing.. Particularly how to make use of metadata about samples in Tidal patterns.

E.g. lets say I had a folder of short sounds, and wanted to play them in order of 'brightness':

d1 $ sound "vocalsnippets*16" # quality "spectral-centroid" saw

This could make use of pre-calculated (or calculated on-the-fly and cached) sound analysis data stored in a different yaml file for each sample.

There's different ways of achieving this..

• Tidal could have access to the file path, and read in the .yaml files itself. One advantage of this is it could then work for OSC targets other than SuperDirt.. e.g. animated gifs being used by a video synth
• Tidal could query SuperDirt for the metadata over OSC, to create cached lookup tables that it can then use in its patterns. An advantage is that Tidal can be quite unconstrained in making use of the metadata, e.g. only applying pattern transformations to quiet sounds
• All the metadata could stay on the SuperDirt side, then simply allowing tidal patterns to pick sounds from a samplebank according to their relative timbral characteristics, e.g. the sound with median brightness.. The advantage is that latency issues aside, it could potentially be on-the-fly, and maybe even done for parts of a sound - sound grains rather than on the sample level

We're leaning towards the first option, as in some ways the most flexible, and probably easiest to implement (at least for me as someone less sclang proficient), but perhaps more than one approach could be taken.

[telephon]

for sound analysis, tidal could use supercollider as engine, and write the data to disk which can then used following your first suggestion.

Then it is up to everyone on what side they want to use the data, so you could also read them from sclang.

[telephon]

These would be the potential sources for information:

• SynthDef: control names, default values, rates (thus, can they be modulated?)
• SynthDef metadata (if given, which depends on the effort): there may be specs for each control
• buffer information (currently, the number of frames and number of channels, but we could add more information there)

It seems to me the question how we want to account for this open ended information. Should it be user extendable or is it fixed?

[yaxu]

As per this forum thread, it would be nice for tidal to be able to now the duration of each sample, so that it could timeshift it so that it ends, rather than starts at a certain point.

This raises a couple of questions

1. Does this go into metadata file, which tidal then reads directly?
2. Does tidal query SuperDirt for this info (on startup or on demand), and if so does SuperDirt read it from the metadata file?

The first option implies that Tidal is on the same host as SuperDirt, which might not be the case. The second option seems better, and perhaps with all such info coming from metadata files - then we could e.g. 'trim off' trailing silence from samples from freesound.org based on that metadata.

[telephon]

The direct implementation of 2. is of course very easy.

The question is – if tidal wants to inspect any data that is in the soundLibrary, one could do it more generally. Also the sound library would probably load metadata, so this would be the central place for it.

Questions:

1. currently, we keep sample (buffer) events and synth events separately. Will the metadata be also separated in this way or should there be a common metadata convention?
2. when we query, we'd probably send something like "/dirt/metaData numNames name1 name2 ... numParameters parameter1 parameter2 ...", and superdirt would send back something like "/dirt/metaData/reply numValues value1 value2 ...", and tidal would reconstruct the names and values? Or we could make it more explicit, sending back all the names, but that would be more redundant and the structure would also be complicated. It is possible to send arrays via OSC, but hen tidal would have to implement that.