FYI: Tidal patterns to B.SEQuencer presets

[sjaehn]

Hi,

I really like the enormous and inspiring collection of drum patterns you made and you published under GPL3. Therefore I made a little tool to convert drum patterns from the format you use to B.SEQuencer step (see https://github.com/sjaehn/BSEQuencer ) sequencer plugin presets: https://github.com/sjaehn/Importpattern. Not all patterns are portable, but some 95%.

It's written in Python. I know it would likely be better if it is in Haskell as well.

I didn't fork your repository, but I linked it in the README.md. I think this would be the most beneficial way for all. What do you think about? BTW, are you open for pull requests?

[lvm]

Hey!

Hi,

I really like the enormous and inspiring collection of drum patterns you made and you published under GPL3. Therefore I made a little tool to convert drum patterns from the format you use to B.SEQuencer step (see https://github.com/sjaehn/BSEQuencer ) sequencer plugin presets: https://github.com/sjaehn/Importpattern. Not all patterns are portable, but some 95%.

Awesome! Really glad that you've found it useful. It began as a quick way to avoid repeating myself. I have this idea of writing a drum (i mean, with a physical / "tangible" drum kit) learning app, but got carried away with other projects. Perhaps some day I'll finish it.
I wonder which patterns aren't portable. Basically i wrote them with "portability" in mind:
Here are the same patterns but in (SC's) Dictionary type
https://github.com/lvm/SuperUtilities/blob/master/classes/DrumLoop.sc

I imagine this Dictionary format is much more closer to the Python's dict object (or even JavaScript) than parsing them from the tidalcycle's format.

It's written in Python. I know it would likely be better if it is in Haskell as well.

Python is perfect. I kinda stopped coding in TidalCycles because i got tired of dealing with Haskell issues :-)
In fact, here's a version (can't seem to find the latest) of how i created / converted this patterns, not the prettist code but does the trick. Perhaps you find this useful: https://gist.github.com/lvm/62f0797ab5e53bfdd6c1e24bbb85fe73

I didn't fork your repository, but I linked it in the README.md. I think this would be the most beneficial way for all. What do you think about? BTW, are you open for pull requests?

Sure, i'm open to PR. I'm not really that active (in the live coding scene) these days but any help is more than welcome. I would even suggest to find a more flexible way to store these patterns (I'm thinking of JSON files since you can practically use it anywhere these days) so it's possible to use them with any language / tool.

PS: I transcribed most of these patterns from books / magazines, just created a couple of 'em (literally, like 2 of them. 4 or 5 max. 😬)

Regards,
Mauro

[sjaehn]

Hi Mauro,

thanks for your response.

I wonder which patterns aren't portable.

Only very few, I think there were only three or so. So I could better write > 99% can be imported.

Expected limitations are in the first line due the pattern size of B.SEQuencer (max 32 steps, max 16 instruments). The number of instruments wasn't a problem at all, but one pattern containing 48 steps was simply too big to import.

The importpattern.py tool is currently limited to the General MIDI standard drums (35 - 81). Thus "sh" (82) can't be imported, yet. Maybe I'll extend this. But then, the MIDI instrument need to support these codes in the expected way too (and this is not always the case).

And in CowBell.hs you use the symbol "cow" instead of "cb".

I imagine this Dictionary format is much more closer to the Python's dict object...

Yes, they are a bit closer. But there are only two steps required to remove all white spaces and square brackets and then to substitute the tildes and the "t"s by 0 or 1, respectively.

And the Tidal patterns contain additional information about the number of beats per sequence and the number of steps per beat. And B.SEQuencer can use this information. Of course, I can also use the SuperCollider data as well. But then I don't have this additional information and I have to use defaults (or user-provided command line parameters) instead.

[lvm]

Hi Mauro,

thanks for your response.

I wonder which patterns aren't portable.

Only very few, I think there were only three or so. So I could better write > 99% can be imported.

Expected limitations are in the first line due the pattern size of B.SEQuencer (max 32 steps, max 16 instruments). The number of instruments wasn't a problem at all, but one pattern containing 48 steps was simply too big to import.

Ah I see, great then!

The importpattern.py tool is currently limited to the General MIDI standard drums (35 - 81). Thus "sh" (82) can't be imported, yet. Maybe I'll extend this. But then, the MIDI instrument need to support these codes in the expected way too (and this is not always the case).

I used the GM2 Percussive key map as reference:
https://www.voidaudio.net/percussion.html
https://www.musicrepo.com/wp-content/uploads/GM2-Drum-Map.txt

On one hands it's more versatile since there are available more instruments to choose, on the other, these are most likely not to be used... 🤷

And in CowBell.hs you use the symbol "cow" instead of "cb".

That's definitely a typo. This is the correct mapping: https://github.com/tidalcycles/Tidal/blob/main/src/Sound/Tidal/Params.hs#L117

I imagine this Dictionary format is much more closer to the Python's dict object...

Yes, they are a bit closer. But there are only two steps required to remove all white spaces and square brackets and then to substitute the tildes and the "t"s by 0 or 1, respectively.

And the Tidal patterns contain additional information about the number of beats per sequence and the number of steps per beat. And B.SEQuencer can use this information. Of course, I can also use the SuperCollider data as well. But then I don't have this additional information and I have to use defaults (or user-provided command line parameters) instead.

Right, i found this to be problematic as well when "translating" from TC to SC, so i opted for the simpler (though not the most accurate).