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

@imthanapat [declare] is an object in Pd. So you would just create the object [declare -stdpath libraryname]. You might need to use the -stdlib flag instead, particularly for libraries like zexy that have all the objects in one file instead of individual files per object. But yeah, take a look at the helpfile for [declare] and see what works.

To do this in real-time, I gotta think you'd need a six-channel pickup to make that happen. On a monophonic input, a granular delay that followed the pitch and then did some pitch-synchronous granular detuning might work somewhat convincingly. But polyphonically on a guitar, there would probably be a need for an extensive library of chord fingerings to analyze along with a good estimation of the likely fingering of monophonic lines given that there are multiple ways of playing the same thing on a guitar using different strings.

That would seriously be a cool effect, though.

@seb-harmonik.ar @ith I actually posted a more accurate [vphasor~] external here if you're interested. My original abstraction was sample-accurate (and vanilla), which is probably fine for most uses. But given that [metro] is sub-sample accurate (meaning it will bang between samples), if you really want to nail the reset perfectly, the external is better. At really high frequencies the difference between the two will likely be a bit more noticeable. At lower frequencies it probably doesn't matter so much, though.

Do you mean it's not exactly 1 ms, or that it just doesn't do anything at all? Because it won't be exactly 1 ms due to the fact that [line~] is limited by the blocksize. It's not necessarily a bug, it's by design. The ramp generate by [line~] will snap to block boundaries. If you need more accuracy, use [vline~].

It's from zexy and it outputs the contents of the array as a list. The arrays are one-dimensional, so you only get the "y-values" (the x-values are just indices. There's also [array get] in vanilla that does this now.

@ricky I haven't tested this extensively, but I think it's working. It uses linear interpolation to estimate the hold value. Could maybe be improved with a 3-point cubic interpolation or something, but I haven't really messed around with that stuff. Like [vphasor2~], it will only work correctly with positive-ramping phasors.

vsamphold~.c

@solipp You can also do that vanilla-style like this:

[0(
|
[makefilename $%s]
|
[obj 100 100 myabs $1(

@ricky those horizontal patch cords definitely look familiar, lol! ;-p I'm sure a [vsamphold~] wouldn't be difficult. I look into it later today.

I haven't used Mac in a while, so sorry I can't be more specific, but it sounds like one of the .plist files you deleted was the one that had the default startup libraries the Pd-extended loads. Do you see libraries listed in the Startup... dialog?

When Pd loads your object, it first looks for a setup function to define things like the object's data space, constructor, methods, arguments, etc. This is a required function. If your object is called [myobject], the function should be called myobject_setup(). So the error message is saying that it tried to load hello_world.pd_linux (in other words, it found it, so that part is right at least), but there is no hello_world_setup() function in the C code.

Take a look again at the helloworld section of the HOWTO you linked for a description of the setup function.