tidalcycles / Clean-Samples

Like Dirt-Samples, but cleaned up
GNU General Public License v3.0
44 stars 4 forks source link

How to represent short identifiers for sounds and sound sets #14

Open cleary opened 3 years ago

cleary commented 3 years ago

Hi @yaxu, I was just revisiting the metadata for my various sample repos -

When generating the cleanmeta file, there doesn't seem to be any reference to the --shortname value in the generated file. It does use this to create the filename I believe ie <shortname>.cleanmeta

As a personal preference, I'd prefer that the shortname be independent of the cleanmeta filename (and not have any dependence on the filename beyond a .cleanmeta suffix) - so I can keep the quark and cleanmeta files named consistently (ie samples-flbass.[quark|cleanmeta], plus guarantee that I know the shortname will be referenced correctly by superdirt (rather than guessing that the cleanmeta filename prefix will be used)

Hope this makes sense, had trouble articulating :/

yaxu commented 3 years ago

Yes agreed. The filename shouldn't be part of the metadata so could be anything, although the shortname is a reasonable default I guess. + yep the shortname should go into the metadata - that's just an oversight that it's missing.

yaxu commented 3 years ago

As per https://github.com/tidalcycles/sounds-dirty/issues/2 ,

So a typical file currently looks like this:

{
  "copyright": "(c) Michael Fischer / Technopolis",
  "description": "TR-808 cowbell",
  "email": "alex@slab.org",
  "license": "cc0",
  "maintainer": "alex",
  "metadata-format": "clean-0.1",
  "shortname": "cb8",
  "sound_type": "sample",
  "sounds": [
    {
      "filename": "cb8/CB.WAV",
      "shortname": "CB"
    }
  ]
}

A metadata-aware tidal/superdirt would allow the above to be accessed as d1 $ sound "cb8:CB".

It doesn't feel quite right to have shortname on different levels, identifying different kinds of things.

That said, I'm used to ids being everywhere in a CSS tree. Maybe we use id instead, does that somehow feel better?

Otherwise we could have set_id and sound_id.. any opinions?

charlieroberts commented 3 years ago

I agree it's slightly confusing to have the same field in different levels... but only slightly, and since both fields serve a very similar purpose I guess I'd argue that it makes sense to name them the same. I'm not sure if you were suggesting this, but I don't like id for one and shortname for the other. set_id and sound_id are good alternatives, but I'm not sure they're better.

yaxu commented 3 years ago

I was suggesting calling it id in both places, as an alternative to shortname in both places.