Great, thanks for the insight.
I'll follow that guide then: [clone] for simple single argument patching, and dynamic when I need more control. I'm quite new to dynamic patching, but starting to get my head around it, using a lot of the [text] object too ...
If it's fine with you, I'll be sharing the toolbox I'm working on soon, and will ask for your feedback? Very grateful for your help on all this.
Many thanks David as always for your quick and insightful reply!
I do not need to comunicate between instances (thanks for the this and next tip though), neither send / receive locally within each instance. The question is if I really need to shift arguments up a notch from non-cloned abstractions: you answered that very clearly.
I guess I need to have a clonable
version and a clone-free version for concerned abstractions ...
I’m trying to [clone] abstractions which already use $1, $2, … for internal send/receive pairs and more. Is there any way to avoid “pushing” argument order in [clone] while still addressing individual instances (-x doesn’t do the job)?
Of course I could replace $1 by $2 and so on inside my abstractions, but it’d be great to keep one version working in and outside of [clone].
Maybe there’s an obvious workaround I’m not seeing, hope this makes sense.
Ok, I give up … at least for now.
I really hope someone someday can come up with a proper off-the-shelf solution easy to implement (Vanilla?).
In the meantime, I’ll go for 2 seperate samplers depending on the use-case:
One for the varispeed but artefacts, another with fixed speed but no artefacts.
If any of you come to conclusions, I’d be glad to share the info I’ve found on the subject.
Yes, this issue is quite essential and poorly documented …
I was aware of both discussions you mention, and couldn’t find a solution there: just confirm the problem.
You’re probably right it’s due to the interpolation, the fact it appears even at nominal speed makes it a mystery.
The onset solution seems to work, both with data and signal onset.
The hard part is to implement them …
I still have hope installing the iem-dp library.
You’re right tabread4c~ doesn’t solve the issue neither.
I’ll probably end up having different samplers do different things: one for fixed speed (no artefacts, read from disk, etc) and one for varying speed.
I’ll keep you updated if I find more clues somewhere.
Thanks for your support
Yes, I got to the same conclusions: there's probably another way to use tabread4~~ without phasor~~ and such, but I'm missing it.
I tried your compiled version on my laptop (osx 10.11.5, Pd 0.48.1) but it doesn't seem to work. I tried with extended too.
I'll check over the weekend with the installation's MacMini, that'll probably work. Tank you, seriously
Thank you very much for taking the time to detail this.
I can’t use [tabplay~] as the artist wants to use variable speed and reverse playback, as well as nominal speed.
Clicks at loop points aren’t a problem as the files are processed to start and end at zero-crossing.
I understand artefacts (with an “e”, thanks for that) are inevitable when playback speed is different from 1. Using filters to eliminate aliasing when speed >1 sounds like a great solution, I’ll look into this (maybe also upsampling in a subpatch, if it’s not too hard on CPU).
However, it seems tabread4~ generates artefacts at nominal speed too!
I’ve modified your patch and attached an audio file where the artefacts show up clearly: reverseMod.zip
The problem is mentioned (with a possible fix) in examples B.15 and B.16, but I can’t get those to work at highly varying speeds, or reverse playback … I understand this is the reason why IOhannes & co came up with tabread4~~, but I can’t get that implemented neither at the moment …
Sorry I wasn’t clear at the start, I hope this all makes more sense?