short answer: because mpeg conversion also includes FFT at one point.

all of these things can be done with various combination of addition and multiplication.

there is no need to measure the RMS of a known waveform, since you can calculate it offline much more precise. the energy of a wave/halfwave/periodic vibration is the size of the geometric surface: 1 for square, 0.5 for tri and saw, 0.707 for sinus...

@andresbrocco

i just read the starting post again - and as it seems i did not do that before asking that question.

it would have been my next question why you do not use coefficients which somebody else made already.

no i havent tested those yet, but i might come back one day with proposals.

in my opinion the usual 16x oversampling is almost unavoidable for FM or PD synthesis.

the attempt to take care of the bandlimiting with prior components has to fail everywhere, where even sinewaves as sources will already hit the nyquist barrier.

oh, you can also make it shorter by writing 10^5

i wonder how you came up with the filter topology and settings and how you were deciding/balancing the filter curve precision vs the LR runtime difference/phase shift.

HRTF FIRs are a beast, and in my experience it already sounds terrible when you take it over to an fft filter.

@jameslo said:

@PD-Pi Wait, if each clone instance is a voice, then they can't share a single phasor because then they'd all have to play the same pitch, which is not my understanding of a polyphonic synth.

the idea of using a central phasor is not that the frequency must remain the same all the time, rather you would derive sub-phasors from it or use forms of distortion - or clock multiplying - while everything can still be resynced from the master.

that is also how you can realize a naive hardsync oscillator among other things.

the master would be outside the clone patch of course.

i dont see the need for that "until loop", if 1000 is not present it would just accumulate another 0.

okay, it might get quite long if you do that for 8 or 10 digits. but a pure arithmetic, one-object solution is possible

(int($i1-(int($i1/10)*10))/1) + (int($i1-(int($i1/100)*100))/10) + (int($i1-(int($i1/1000)*1000))/100) + (int($i1-(int($i1/10000)*10000))/1000) + (int($i1-(int($i1/100000)*100000))/10000) + (int($i1-(int($i1/1000000)*1000000))/100000) + (int($i1-(int($i1/10000000)*10000000))/1000000) + (int($i1-(int($i1/100000000)*100000000))/10000000)

feel free to make it a bit shorter using modulo operator - i´d prefer it like so.

saw and square sound louder because they have the most overtones.

square has also actually the most energy.

i would not use different amplitude factors, that is the job of the patch designer.

@oid
i wonder what you think what this feedbackloop should be good for.

the image from fishcrystal contains an important, basic part of the answer in that plot: the math required for a multi-point-crossfader is identical to the math in a "equal-power" stereo panner.

using modulation -> list -> modulo -> cos function, as seen above, is a nice short data rate implementation.
if you want to use signals, where you dont have lists, you can optimize that principle further by using buffers and then only use +- offsets when reading out the function for the different inputs.

if you have a function or graph with more than one dimension, like in your example or in the usual chaotic attractors, you would simply take these dimensions individually and derive 3 signals from it.

then you can take only one of them, or mix them against each othe, or sum them, or multiply them squared or whatever you wish.

in order to do so, you would simply rebiuld the code so that it produces values betwee -1 and 1, (which can get tricky when used a low resolution arithmecis before), and when it works, you´d make a version with signal objects (which is often simpler than you thought)

i would say "no" - there is no known generator or filter which is polyphonic by nature.

even if you code your own external at one point you always have to iterate the list into single values.

for example you could use a vexpr object instead of 4 mtofs, but there is no method how to make a polyphonic phase accumulator.

if you would try to make one, you would soon find out that it does not make too much sense to process accumulators in vectors when you need to have single outlets anyway, since audio connections have a fixed rate and bitdepht and can not be used to carry more than one signal.

of course inside pd you can yourself freely *where *you do that, (as opposed to MIDI, where every communication is serial.)

wow that is closer to live than to max.

oh, i wasnt aware of that at all. so one could say there is basically no main thread? when the scheduler cant be turned off.:)

(scheduling events works fine: metro 1 -> click~ at vectorsizes 32 does what it is supposed to - in max it required the hp-thread to be available or it would produce hiccup.)

@Chalisque

short answer: you have to make sure that the data runs in the high priority thread.

pd and max have a main thread, a high priority thread (overdrive), and an audio thread (among others)

how to do that in C++ is surely documented in the SDK examples, but i will not be of much help here.

maybe compare the source code of [+ ] vs. [delay], the latter outputs to the high priority thread if one exists.

@jamcultur said:

Thanks. That might be what I need, but I need to do some more research on MIDI MPE messages. I'd like to find a MIDI MPE sample file that I could download. I see that Max/MSP added some new objects for MPE, mpeconfig, mpeparse, mpeformat, polymidiin, and others. I'm going to look to see what they're doing.

a file would not be as helpful as simply looking into the specs. the basic "polyphony" releated stuff is relatively simple, the only prerequisite would be that midiin and midiout do not filter out numbers they dont know.

max´s mpeparse or midiparse are quite useful, but it is not really difficult to write your own, it is basically sorting numbers.

if the duration is the same for all notes, there is no need to process them as numbers, you could as well store and trigger the list as such.

you will benefit from that in many other situations, for example it then will also work with an arbitrary number of list elements.

at least you can remove all but one pipe objects in that patch.

another alternative design would be to add the duration to each note, as it will be required to do that when assembling te midi events anyway. if you do it this way, you will also add the option to use different durations for each list member, something which cen get quite relevant for musical events.

alltogether i would say you dont need that patch at all to do what you want, you basically only need to bang the messagebox and then do the midi formatting.

in theory by upsampling the whole process.

but in most cases you would then also need to play the input faster into it.