Closed tgirod closed 3 years ago
That sounds like a useful development to me. I think the right way might be to make tidal looper a quark and change it's prototype status to a real SuperCollider class. When creating an instance, you could then say that a SuperDirt instance (~dirt) must be passed. Then one could also configure and control different behaviour, which could extend the functionalities. And as you said, it would have the advantage of being easier to install and update.
By the way the tidal looper already uses SuperDirt's event system, so I'm unsure what you mean by "Superdirt synth".
Next weekend I plan to deal with the further development of the tidal looper and then look at it in detail. If you have interesting sources or other approaches until then, feel free to post them here.
By the way the tidal looper already uses SuperDirt's event system, so I'm unsure what you mean by "Superdirt synth".
I just mean that tidal synths are expecting a series of standard parameters, but you are right tidal-looper synths are already doing just that.
I left the old Looper.scd in the repository so it is backward compatible for now. I implemented the basics once myself, since I still knew how to set up a Quark and I had already worked out ideas how and which interfaces I want to offer.
I'm still unsure how I'm going to do this with the releases, though. In addition, TidalLooper as Quark should also be tested extensively before I include it in the official Quarks list.
Nevertheless, the TidalLooper can now be installed as Quark.
tidal-looper would benefit from a better integration in the ecosystem:
I'm not very familiar with the supercollider ecosystem, but I can have a look ...