@LiamG said:

@whale-av [list trim] gets rid of the symbol selector too! Took me years to figure that out.

Woah, I've been trying to figure out for the longest why my state-saving abstractions forget that symbols are symbols. This never occurred to me. Now I can probably fix them, thanks!

I think you'd be better off having the note offset occur in the voices themselves (i.e. after [poly]). That way you aren't screwing with the actual MIDI note value before it hits [poly], and therefore it will be able to keep track of the notes.

It's a loop error because each DSP object in Pd passes samples in blocks (or vectors) from one to the other. By default the block size is 64 samples. But whatever the block size is, Pd has to process one object at a time, passing the blocks from one to the other. When you directly connect them via patch cords, it isn't necessarily clear to Pd which one should be processed first. The order is important to get the behavior that is expected. So whichever one Pd chooses could lead to different results.

The preferred way to do feedback is to go the cordless route, such as using [send~]/[receive~] or using the delay objects. Pd understands this better because it knows to read from [send~]'s (or [delread~]/[vd~] if using delay objects) block first, pass it through whatever patched objects that process it, then write to [receive~] (or [delwrite~]) before going through the next dsp loop. Keep in mind, however, that using this route the feedback will be delayed by at minimum the size of the block. So in your abstraction the feedback is delayed by 64 samples. If that's fine, then go for that. If not, lower the block size using [block~ 1]. But only do that if you really need it, because lowering the block size can significantly increase the computation load.

Take a look at G01 - G05 in the audio examples in the help browser for more clarification on this.

They don't have to be added to the startup flags. You can use [declare -stdlib Gem] and [declare -stdlib zexy] to load them.

I haven't used Mac in a while, but you should be able to install the command line tools without installing all of XCode.

Yes, you could test it using [realtime] and an [until] to run the process a bunch of times.

You shout used outlet_list() instead of outlet_float().

outlet_list(x->x_out, &s_list, n, argv)

where x->x_out is the pointer to the outlet, n is an integer representing the size of the list, and argv is an array of type t_atom containing the list elements.

If you look at Pd's source code, there is a file called x_list.c that contains the code for the list objects. It might help to look through that.

Maybe [folder_list] from the hcs library will help.

You might be better off just using [bonk~] to trigger the hits, as it will detect transients and give you a velocity.

I don't think that's a Pd thing. It's likely the adc from your audio interface is doing the low-pass filtering. If you want to keep the crap, record at a higher sampling rate and then downsample.

Edit: to clarify, analog-to-digital converters have built-in low-pass filters to ensure that the digital recording doesn't alias. When you set Pd to a lower sampling rate, it's telling the adc in your audio interface to set its low-pass filter so that it won't alias when it records. So if you want the aliasing, you'll have to record at a higher sampling rate first and then downsample without filtering.