• yannseznec

    (sorry not to respond to your email yet - I'll respond on here instead!)

    scraping data from the internet isn't the easiest thing to do in Pd, in my experience, I think the solution @andresbrocco describes is probably best. It's (annoyingly) easier to do in Max/MSP, but hey.

    In terms of sensor data from a micro controller - in my experience the most dependable way is to code a Teensy micro controller to function as a USB MIDI device. You connect any sensors you like to the Teensy, and convert the data into MIDI CC or note values, which can be read in PD using the [notein] or [ctlin] objects. This is a really solid and relatively straightforward method...I have some generic code for doing that on my website: https://www.yannseznec.com/works/teensy-usb-midi-controller-code/

    For most things you can just use a Teensy LC, which is only like £12 or something.

    The primary downside of that method is that the resolution is quite low, because MIDI is so old fashioned. So it means that whilst you can get 12 bit analog input resolution on the Teensy (values between 0-1023), you have to downsample that to go from 0-127 for it to work over MIDI. so that kind of sucks. However, if you really want high resolution you can be clever with numbers and split them up and send them over several CC controller numbers or something, which is sort of how NPRN works.

    Hope that helps!

    posted in technical issues read more
  • yannseznec

    This is the first release from my Book of Knowledge of Impractical Musical Devices: A Day That Will Never Happen Again.

    It's a sample-based rhythm generator that sounds different each day that you use it. It’s about memory, and our futile attempts to recapture time.

    Built entirely in Pure Data, running on a Raspberry Pi with a Teensy. All of the code and background information about the instrument is available from the project website: http://www.impracticaldevices.com.

    Two more volumes will be released in the coming weeks!

    posted in output~ read more
  • yannseznec

    @ingox said:

    You can also use [array size $2] instead.

    This works perfectly, without errors. Thanks!

    posted in technical issues read more
  • yannseznec

    Sorry not to be clear - the screenshot I've put there does work in exactly the way I want, it just throws the errors in the Pd window as described. Strange?

    posted in technical issues read more
  • yannseznec

    I've set up the following method for resizing arrays in a subpath:
    Screenshot 2019-07-30 at 09.33.03.png

    This seems to work exactly how I want, however in the Pd window I get the error: *: no method for 'resize'

    What does this mean? I thought I had done it this way before without issues, but obviously I'm doing something wrong.

    I recognise that the "correct" way is to use the array object now, but I rather like having the graphical representation in this instance!

    posted in technical issues read more
  • yannseznec

    Just wanted to pop back here to say thanks! @solipp @whale-av @weightless
    I've finally managed to get back to this patch and try out some of the techniques you all mentioned (namely using line~ and the offset system in tabread4~) and it's sounding much better and it has opened up a few new sonic possibilities. I'll post updated patches soon!

    posted in patch~ read more
  • yannseznec

    @solipp said:

    one benefit of using line~ instead of phasor~ is that it allows you to trigger the grains rhythmically or to have gaps between the grains. Also, with line~ you don't have to use a workaround like threshold~

    "similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~"

    not in this case. you'll get some distortion and the end of a longer table (more than 32k samples) It's documented in B15-tabread4~-onset.pd

    You should not get clicks with [switch~] when you do the windowing of your grains right.


    ok that's all super interesting! I guess I still see a downside in terms of needing to trigger the line~ envelopes using a (non-signal rate) bang, but is that not really an issue in practice?

    thanks so much, this is all so helpful.

    posted in patch~ read more
  • yannseznec

    @whale-av said:

    @yannseznec Yes, switch will cause a click, but you can take the output of the patch down first and bring it back up after with a [line~]
    It has a side effect that any [readsf~] playback is paused, and a delay line like [delwrite~] is frozen.


    ah yes of course, this makes sense!

    posted in patch~ read more
  • yannseznec


    Thanks so much for all the tips and for sharing the patch! I'll definitely have a look.

    @weightless said:

    I have also included your piano sample, hope you don't mind! :)

    you can pay any royalties to my two year old :)

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!