@whale-av @beep-beep that's great, thanks!

Hello!
Is it possible to put a variable name in the "Send symbol" and "Receive symbol" fields in a UI object property window?

using an Hslider, for example, I don't seem to be able to fill those fields with "slider_$0", this gets automatically changed to "slider_0".

I know I can connect a message box to the slider to change this, and I know I can send a remote message with a message box (using the receive symbol), but I'd love to be able to just fill those two automatically with a unique number for each patch.

Does the question even make sense?

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

@RetroMaximus thanks!

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!

@ingox said:

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

This works perfectly, without errors. Thanks!

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?

I've set up the following method for resizing arrays in a subpath:

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!

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!

@solipp said:

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

cheers!

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.