• Gabriel Lecup

    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.

    posted in technical issues read more
  • Gabriel Lecup

    One more thing: it seems I can avoid the problem by dynamically creating instances of the abstractions I need to clone ... Is there any reason to use clone rather than dynamic patching?

    posted in technical issues read more
  • Gabriel Lecup

    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 ...

    Thanks again!

    posted in technical issues read more
  • Gabriel Lecup


    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.

    posted in technical issues read more
  • Gabriel Lecup

    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.

    posted in technical issues read more
  • Gabriel Lecup

    @whale-av said:


    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 !!!


    posted in technical issues read more
  • Gabriel Lecup

    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 !!!

    posted in technical issues read more
  • Gabriel Lecup

    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?

    Thanks again,


    posted in technical issues read more
  • Gabriel Lecup


    Thank you so much for the replies, I hadn’t turn on notifications so took a while to see those.

    The problem is really artifacts produced by tabread4~~ in the “classical” implementation (that of your patches). You won’t notice those with a voice due to complex spectre and dynamics, but they clearly show up on continuous high-pitched drones …
    It’s a known (and quite essential) issue, but surprisingly there’s no easy solution to this it seems.

    Ok, good to know I’m not the only one ;)

    I’ve been using Pd-extended for this project, so tabread4~~ comes included.
    However, the rest of the iem-db library isn’t. This is rather strange if it’s needed to run tabread4~~ properly ...

    I confirm the iem-dp library is neither on deken, nor Pd-extended, nor Purr-data.
    I’m trying to avoid compiling for 2 reasons:

    • Never done it (and not much of a coder).
    • We develop the project on different OSX.

    I’m beginning to think there’s no other way, so I guess I’ll have to give it a go … Your patches seem to solve the problem!


    • Someone out there can explain how to use tabread4~~ without other iem-dp objects (phasor~~, add__, etc)?
    • Someone knows of a compiled version of iem-dp?
    • The problem (artifacts) is solved in a different way in Purr-data?

    Many many thanks for your reply, it seems there’s finally light at the end of the tunnel.
    Once again, it’s such a core issue I’m surprised there’s no simple solution, and I’m sure many could benefit greatly from one …
    Will get back with conclusions when they come around.


    posted in technical issues read more
  • Gabriel Lecup

    Hello forum!

    First post here, not all that new to Pd.

    Basically, I noticed nasty artifacts using phasor~ to read a buffer with tabread4~, and not just on large files. It seems like a known issue, and fixes/workarounds appear over the years in different threads.

    However, I am not able to find a clear up-to-date solution to do this:
    Nominal + variable + negative (reverse) playback speed
    No artifacts
    Long audio samples (20min)
    Looping on/off with no clicks
    Read from buffer OR disk (either is fine, buffer is better)

    My best guess at the moment is to combine the Pd example B.16.long-varispeed.pd with the tabread~~ object, but I’m having trouble implementing this.
    Does someone have a working example using tabread4~~?
    Can this include reverse playback of a sound file?
    Is there a better solution out there, such as (not limited to): moonlib/sfread2~, readanysf~, xsample~, …

    Thanks in advance for your help.
    I’m sure this is something many of us would be interested to clear up.


    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!