Fora

I was hoping somebody could point me in the right direction. I am trying to translate a PD patch into Max and I can't figure out how to mimic PD's [bang~] 

'output a "bang" message after each DSP cycle'

I was hoping somebody could point me in the right direction. I am trying to translate a PD patch into Max and I can't figure out how to mimic PD's [bang~] 
'output a "bang" message after each DSP cycle'

Hi guys, 
I was hoping somebody could point me in the right direction. I am trying to translate a PD patch into Max and I can't figure out h

pure-data-bang~-equivalent

Great, I was doing some more research into PD vector size and yes, like you said it's fixed at 64 vs.

Many thanks, I'll give this a go, I think this will do the trick nicely!

no prob (i had an extra bang in my original patch above [adstatus sigvs] going directly into it, the helpfile said this was to report "...choices" (as if to populate a menu of choices to choose from), but apparently, it just selects the actual value and the menu for the helpfile was prepared in advance,....either that or that object reporting vs 'choices' works differently than i remember... sorry to rant, anyways, i edited the patch above / reposted ...i'd double-check with the 'Audio Status' window to make sure the patch is actually selecting a vs of 64 on your system) 🍻

Appreciate the update, I ended up stripped away most of it and kept the gen -> edge.

Raja you're a total legend, many thanks yet again!

Oh just in case you're curious, I am trying to port martin brinkmann's small Paul patch

niiiiice! (with the paul stretch algo in it) 

trying to port martin brinkmann's small Paul patch

niiiiice! (with the paul stretch algo in it) 
would love to see it when you're done :)

yeah that's the one but my patching skills have subsided after a long hiatus away from Max so it may take slightly longer than expected!

Cool, I'll post it here if I manage to complete it!

Wondering if I could pick your inter-dimensional brain for a moment?

I am facing a issue trying to replace two PD objects, hoping you might know a good replacement for these two..

I have a feeling I could replace [block~] with poly~

Wondering if I could pick your inter-dimensional brain for a moment? 

I have a feeling I could replace [block~] with poly~ 

sending a signal into snapshot~ should also do it?

Many thanks for chiming in Roman and please correct me if I am wrong but I don't think snapshot~ is correct in this instance, as part of the original PD patch the object tabreceive~ is driving a Hann function.

tabwrite~ has been replaced with [poke~] and Andrew Benson's gen [cshot~] btw

I have attached a screenshot section of the PD patch..

Screenshot 2018-10-26 at 10.45.40.png

I have included another screenshot of the whole patch in case anybody wants to see it for better context.

Screenshot 2018-10-26 at 10.54.46.png

Also this was taken from PD's help guide..

tabrecieve~ '- read a block of a signal from an array continuously'

edited*

Many thanks for chiming in Roman and please correct me if I am wrong but I don't think snapshot~ is correct in this instance, as part of the original PD patch the object tabreceive~ is driving a Hann function.

tabread~ has been replaced with [play~]
tabwrite~ has been replaced with [poke~] and Andrew Benson's gen  [cshot~] btw

Also this was taken from PD's help guide..  

i think Roman was answering your first question, and now that i look, he's right! snapshot~ can also do it(i didn't realize snapshot~ now has the ability to register its interval in samples, always thought it was only milliseconds, haven't used that object in years XD, so you could just use [snapshot~ @interval 64 samples], attach some signal to its input([sig~ 1.] is good enough), a bang to its output, and easy-peasy :D)....

as for the tabreceive~ stuff, unfortunately, i never got heavily into PD enough to even venture into fft there, but it does seem like tabreceive~ might be managing a hanning window over the input 'blocks' to the rfft~ object(according to this: 

https://forum.pdpatchrepo.info/topic/3781/don-t-understand-tabreceive/4

... it's just a way to read a block of samples (blocked out differently than the usual block-size of 64 in PD by using the block~ object there as well) and it's likely these are just the equivalent of an "FFT size" and additionally the tabreceive~ object might also map a hanning window over every block)

in Max, you might not even need to use this since pfft~ can do alot of this for you.

in any case, i'm pretty sure it's just windowing(using hanning window) the input/output of the rfft~/irfft~....

since this fft stuff is a bit more complex to explain (and i'm no expert in the way the two environs behave differently between their individual fft solutions), best thing i can do is point you to some of the stuff that has helped me work with fft specifically in Max.... here's one of the best things i've read specifically relating to Max and fft in general as well as the differences involved in going between fft~ and pfft~(which might be a similar difference to going between PD's rfft~ and Max's pfft~):

https://cycling74.com/tutorials/the-phase-vocoder-%E2%80%93-part-i

https://cycling74.com/tutorials/the-phase-vocoder-part-ii

There's also this 7-part tutorial, but it might be more beginner-level than what you need, still an excellent source of info.:

https://cycling74.com/tutorials/advanced-max-ffts-part-1

hope something there can help you out. that's probably the best set of guesses i have. best of luck!

i think Roman was answering your first question, and now that i look, he's right! snapshot~ can also do it(i didn't realize snapshot~ now has the ability to register its interval in samples, always thought it was only milliseconds, haven't used that object in years XD,  so you could just use [snapshot~ @interval 64 samples], attach some signal to its input([sig~ 1.] is good enough), a bang to its output, and easy-peasy :D)....

as for the tabreceive~ stuff, unfortunately, i never got heavily into PD enough to even venture into fft there, but it does seem like tabreceive~ might be managing a hanning window over the input 'blocks' to the rfft~ object(according to this: https://forum.pdpatchrepo.info/topic/3781/don-t-understand-tabreceive/4... it's just a way to read a block of samples (blocked out differently than the usual block-size of 64 in PD by using the block~ object there as well) and it's likely these are just the equivalent of an "FFT size" and additionally the tabreceive~ object might also map a hanning window over every block)
in Max, you might not even need to use this since pfft~ can do alot of this for you.
in any case, i'm pretty sure it's just windowing(using hanning window) the input/output of the rfft~/irfft~....
since this fft stuff is a bit more complex to explain (and i'm no expert in the way the two environs behave differently between their individual fft solutions), best thing i can do is point you to some of the stuff that has helped me work with fft specifically in Max.... here's one of the best things i've read specifically relating to Max and fft in general as well as the differences involved in going between fft~ and pfft~(which might be a similar difference to going between PD's rfft~ and Max's pfft~):
https://cycling74.com/tutorials/the-phase-vocoder-%E2%80%93-part-i
https://cycling74.com/tutorials/the-phase-vocoder-part-ii

There's also this 7-part tutorial, but it might be more beginner-level than what you need, still an excellent source of info.:
https://cycling74.com/tutorials/advanced-max-ffts-part-1

hope something there can help you out. that's probably the best set of guesses i have. best of luck!


Thanks for clearing that up for me Raja and my apologies to Roman, in regards to [bang~] yes, snapshot~ @interval 64, will explore the new features of snapshot~, same here, I haven’t explored it in awhile!

Right, ok I'll will delve into your suggested links and see what kind of solution I can come up with!

Raja and Roman, many thanks yet again, two long term legends chiming in, I feel blessed!

Thanks for clearing that up for me Raja and my apologies  to Roman, in regards to [bang~] yes, snapshot~ @interval 64, will explore the new features of snapshot~, same here, I haven’t explored it in awhile!

Raja and Roman, many thanks yet again, two long term legends chiming in, I feel blessed! 

i was only guessing around, fine that i hit it. 

i was more thinking that it only spits out data with the first sample of every vector (which would mean that it stopped working when someone has a vectorsize bigger than the sheduler time(?)) (or when i am wrong about this)

i was only guessing around, fine that i hit it. 

but are you sure about 64 samples?

btw: count~ and zerox~ could be an alternative.

count will start counting when you turn audio on, so a certain number from it is always in sync with the beginning or any other position of the signal frame.

btw:  count~ and zerox~ could be an alternative.

count will start counting when you turn audio on, so a certain number from it is always in sync with the beginning or any other position of the signal frame.


I didn't think about that, I am planning to run the patch inside poly~ because of pd's [block~] 

so I am wondering if snapshot~ is still a good option?

Raja posted a nice gen solution above which I may use instead just to make sure.

I didn't think about that, I am planning to run the patch inside poly~ because of pd's [block~] 
so I am wondering if snapshot~ is still a good option?

pfft~ is basically a poly~-wrapped fft(i think the 'p' stands for 'poly~'), it might be everything you need.

i think it stands for patcher (it is not very polyphonic)

regarding pd´s bang~, i wonder how it is used? where would you need to know when an audio vector begins (or ends) but with the inaccuracy of control messages?

it should make no difference. poly also only starts processing with the next vector. (including when it has a vector size and/or samplingrate different from the enviroment.)

 I didn't think about that, I am planning to run the patch inside poly~ 

the 'polyphony' part of pfft~ comes through in processing multiple fft-bins(@Roman, i've heard you write on these forums, that FFT is your weakest area😅: you should really try to understand it more, pfft~ is one of the easiest things to use. i say it with love 😘)

@Fora, i'll leave you and Roman to it, but don't get too bogged down by what we've said here, just go with your gut(and pfft~ is your friend 😁).

the 'polyphony' part of pfft~ comes through in processing multiple fft-bins(@Roman, i've heard you write on these forums, that FFT is your weakest area😅: you should really try to understand it more, pfft~ is one of the easiest things to use. i say it with love 😘)

@Fora, i'll leave you and Roman to it, but don't get too bogged down by what we've said here, just go with your gut(and pfft~ is your friend 😁).



thanks for the responses guys, unfortunately I am walking deeper into murky depths as fft is way outside my comfort zone! I should take some time to look at some of the basic tutorials that you linked above @raja.

I was hoping I would find some 'like for like' ports of some of the pd objects and move along with the port rather swiftly but alas, it's a bigger undertaking than I originally planned!

Although I found a couple of pd substitutes on this forum, specifically [tabwrite] (which essentially two objects [cshot] and [poke]) but I can't get it to work as intended.

I am also having a hard time getting a replacement for [tabreceive], I am still figuring out how it works.

block~ 'block, overlap, and resampling control for DSP' I read somewhere poly would be the choice solution, but before I can experiment, I still need to get the audio engine working.. sigh

I came across Volker Böhm's vb.stretch which is similar to Paulstretch, it sounds great but it's osx only, I would rather have a solution I can use without the need for relying on externals.

TL;DR fft seems like the way to go but I need to brush up on the tutorials before progressing!

anyway, thanks for the help guys. I may put this idea to rest for now.

but if anybody else is reading with experience using PD, I would love to know of any decent ports of the tab (series) of audio objects!

thanks for the responses guys, unfortunately I am walking deeper into murky depths as fft is way outside my comfort zone! I should take some time to look at some of the basic tutorials that you linked above @raja. 

I was hoping I would find some 'like for like' ports of some of the pd objects and move along with the port rather swiftly but alas, it's a bigger undertaking than I originally planned! 

Although I found a couple of pd substitutes on this forum, specifically [tabwrite] (which essentially two objects [cshot] and [poke]) but I can't get it to work as intended. 

I came across Volker Böhm's vb.stretch which is similar to Paulstretch, it sounds great but it's osx only,  I would rather have a solution I can use without the need for relying on externals.

TL;DR fft seems like the way to go but I need to brush up on the tutorials before progressing! 

anyway, thanks for the help guys. I may put this idea to rest for now. 

but if anybody else is reading with experience using PD, I would love to know of any decent ports of the tab (series) of audio objects! 

Another idea would be to port Paul Nasca's paulstretch code into gen~

https://github.com/paulnasca/paulstretch_cpp

but that's C++ and another level for me completely!

Another idea  would be to port Paul Nasca's paulstretch code into gen~

this is why i replied to this thread. i also wish a had an 1:1 translation library (except for very similar objects, that wouldnt make sense) but i am too lazy to do it on my own and without reason.

somebody once gave me that as pd[samphold~], which is one of the more complicated ones:

 I was hoping I would find some 'like for like' ports of some of the pd  objects and move along with the port rather swiftly but alas 

this is why i replied to this thread.  i also wish a had an 1:1 translation library (except for very similar objects, that wouldnt make sense) but i am too lazy to do it on my own and without reason.

 #P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 139 181 53 196617 >~ -1;
#P newex 217 199 53 196617 gate~;
#P outlet 343 217 15 0;
#P inlet 61 148 15 0;
#P inlet 139 73 15 0;
#P newex 260 164 53 196617 sah~;
#P newex 343 164 53 196617 gate~;
#P newex 428 146 53 196617 ==~ -1;
#P newex 139 128 53 196617 change~;
#P connect 0 0 8 0;
#P connect 0 0 1 0;
#P connect 5 0 3 0;
#P connect 5 0 2 1;
#P connect 7 0 6 0;
#P connect 2 0 6 0;
#P connect 1 0 2 0;
#P connect 1 0 3 1;
#P connect 3 0 7 1;
#P connect 8 0 7 0;
#P connect 4 0 0 0;
#P window clipboard copycount 9; 

Cool, samplehold is also something I found here, its featured in the patch I was trying to port.

I have a collection of PD ports from Stefan Tiedje called st.tools, there's a folder called Pd abhaXions, really nice collection.

Cool, samplehold is also something I found here, its featured in the patch I was trying to port. 

@Roman, I was researching a PD post entitled "Don't understand tabreceive" which Raja linked and found two bits of info in regards to the behaviour of the tabreceive and block objects which I have quoted below..

"Basically, what it does is cycle through a block's worth of array elements aligned with each block. So if your block size is 128, then [tabreceive~] will spit out the first 128 elements of the array on each block, one element for each sample. It's kind of like having a [phasor~] with the frequency quantized to the block frequency (sample rate/block size) and phase quantized to block boundaries, and then having that [phasor~] read the array."

Possible to recreate this using index / phasor etc?

Block; - Am I correct in saying this sounds a lot like Poly~?

"From what I understand, blocks are essentially buffers meant to make audio computation more efficient. If every sample had to be calculated individually, that means computation must happen at the sample rate (for example, 44100 times per second). Blocks (also referred to as vectors in other programs) allow calculations to be performed on groups of samples. By default, Pd uses blocks of 64 samples, but this can be adjusted per patch/subpatch using [block~]. This can help streamline the code so that some variables that don't need to be updated at every sample can be initialized at the beginning of the block, and then loops can be run on the 64 samples using only the necessary code. It also gives the cpu a little bit of leeway; in case computation falls behind (as a result of other processes interfering, for example) it has some headroom to catch back up."

Regarding tabreceive;

"Basically, what it does is cycle through a block's worth of array elements aligned with each block. So if your block size is 128, then [tabreceive~] will spit out the first 128 elements of the array on each block, one element for each sample. It's kind of like having a [phasor~] with the frequency quantized to the block frequency (sample rate/block size) and phase quantized to block boundaries, and then having that [phasor~] read the array."

Possible to recreate this using index / phasor etc?

Block; - Am I correct in saying this sounds a lot like Poly~?

recreating pd:tabreceive sounds superflous, in my opinion you would normally use cycle (pd:osc) and a send/receive. or no send/receive at all.

some people would design that thing above completely different, even in pd. :)

poly can change the vectorsize only _inside the subpatcher, so a max recreation of the block~ object itself will not work. (i think the runtime would have to allow different vectorsizes in one patch, too, and it currently doesnt. you can only control it globally.)

recreating pd:tabreceive sounds superflous, in my opinion you would normally use cycle (pd:osc) and a send/receive. or no send/receive at all.

some people would design that thing above completely different, even in pd. :)

poly can change the vectorsize only _inside the subpatcher, so a max recreation of the block~ object itself will not work. (i think the runtime would have to allow different vectorsizes in one patch, too, and it currently doesnt. you can only control it globally.)

multirate would be way cooler to have anyway. :)


true, it seems poly wouldn't behave like how I would want block to behave.

I just thought it would be nice to try and port this PD patch but man, I have been exploring options for the last couple of days and I guess I will lay it to rest but it's driven me to explore FTT in more depth which is a good thing.

I am going to continue my exploration of PD as well, it's still a good environment for porting patches into different O/S' and hardware setups (Raspberry PI)

Anyway, let's call it a day on this chapter Roman. Cheers for your input as always! :)

Hey, here you are fighting against one conceptual difference between pd and Max ! you’d rather understand first what’s happening in pd world, an dthen recreate it using Max’s paradigms.

in max there are no bang~ ; block~ ; tabreceive~ . instead there is pfft~, fftin~, fftout~, fftinfo~ (?). rfft~ and rifft~ could be replaced by fft~, but given the context, they are sort of closer to fftin~ here.

Hey, here you are fighting against one conceptual difference between pd and Max ! you’d rather understand first what’s happening in pd world, an dthen recreate it using Max’s paradigms.
in max there are no bang~ ; block~ ; tabreceive~ . instead there is pfft~, fftin~, fftout~, fftinfo~ (?). rfft~ and rifft~ could be replaced by fft~, but given the context, they are sort of closer to fftin~ here.

here's a version attached, it is by no means the correct/exact port... but it's just my effort within pfft~(after researching a bit, the way i was thinking of doing it was to model after the phase-vocoder-tutorial part 1 where they use the regular fft~ object, but do it within a pfft~ and then only use the fftout~ part of pfft~, but in order to do this, you'd have to switch the phase of the fftout~ 180º from fft~, and it appears things have been altered around Max6 so that we can't mix and match techniques like that(you either have to use all pfft~(with fftin~/fftout~ within it, and these automatically take care of the phase-switch, windowing, and sync for you) or you do martin's way with fft~/ifft~, but PD objects have a different method of control which is hard to replicate in Max, i'll explain further below...)

some things i changed about martin's math: 

-he had two separate noise~ sources(and i don't think this was correct: because he had one of them going into [-~ 0.25]->[cos~] and the other just to [cos~], if you send the same noise~ source through both, you have the same signal phase-shifted by 90º(one going through sine and the other through cosine; this is known as a signal in 'quadrature'....i am also not completely fresh on this stuff, coming back to max after a 2 year-hiatus, so i could be wrong... but some of it is coming back to me...)... in any case, i definitely don't think having two separate noise sources and one going into [-~ 0.25] would be correct/necessary because it's noise~ and if you have two separate noise~ objects, they will have completely different outputs and there's no reason to subtract [-~ 0.25] from one to turn it into the sine equivalent in that case(hope y'all follow me, i doubt i'm explaining this well, but i'm pretty sure of this). whereas, if you have 

 noise~ source feeding both routes, then it will create the sine version of the cos~ in that manner properly.

-another thing is he was multiplying by 3, then dividing by 2 in one place, i just changed this to a multiply by 1.5 since that's the same thing, and then in that same area, he was doing a signal-divide(/~) which is more expensive than a multiply(*~), so i inverted the divisor there to turn it into a coefficient by which to multiply and use *~ instead

-block~ : this object, as you know is blocking out the vector-size differently in the subpatch from the rest of PD(which is normally 64), but it also has the option for 'overlap' which is shown in the PD patch by '4' as an argument(this is important for FFT).

-bang~ : you already know this, but just to be thorough, bang~ will bang at the beginning of each vector according to the block/vector-size within that subpatch. we can think of the PD subpatch as a dedicated subpatcher for fft~ processing only, so the bang~ helps to synchronize feeding the rfft~ object with a block full of audio(along with a properly synced accompanying hanning window)

-tabread4~ : this is the playback mechanism for the audio-input to rfft~, it's just a sample-playback object which incorporates some kind of interpolation

-tabwrite~ : it isn't shown in your patch pic above, but when i looked at the PD patch, there's a window next to it which shows the hanning window written into an array using this object

-tabreceive~ : this object automatically reads through the array written into by tabwrite~ and is automagically synchronized to the block

-table : the table object labeled, "$0-hann" is the same table which 'tabwrite~ $0-hann' writes into when the patch first starts up, and is the same table from which 'tabreceive~ $0-hann' reads the hanning window synchronized to the processing of the samples of the subpatch's vector/block

(tabreceive~ is actually a really cool feature of PD, automatically synchronizing readout of an array with the processing of samples according to it's local block~'s size/overlap/etc.)

long story short: my pfft~ here (called "SmallMaul" 😋) is not a correct approximation, but it might help see how some things work(i'm just going by the basic idea of disregarding phase, using only the amplitude of each frequency bin, and then throwing noise into the mix especially on the phases... and i believe it's not even phase or amplitude that he is working on but simply real/imaginary(you need to translate to amp/phase using cartopol~ or do more complex math). basically, in trying it out, i was wrong: and you should probably try to do this with fft~ and ifft~ objects(don't use pfft~.... and by the way, poly~ won't help anything here in terms of the fft-processing itself, if you want to add it later to save CPU overall that's fine but it isn't necessary for the patch to work in Max, you can simply synchronize everything with count~ the way the phase-vocoder tutorials do before the whole fft-processing part). unfortunately, using fft~ and ifft~ is a bit more complex, but that's probably a good thing because this form of complexity will match closer to the original PD patch.

anyways, i doubt anything i wrote made sense, but i tried my best 😆 (i'm terrible at explaining FFT... and to be honest, as i learn it better and better, i'm realizing, i probably don't want to get good at explaining it(lest i were to get paid specifically and handsomely for that 😂), because it is a great deal of work to comprehend let alone explain... my humblest apologies for falling short there).

if you're not trying this anymore, no worries, i just didn't want you to go away completely empty-handed.

hope it helps even if just a little :) best of luck, and sorry again i couldn't be of better assistance ✌️

SmallMaul.zip

sorry if i pushed too hard 😅
here's a version attached, it is by no means the correct/exact port... but it's just my effort within pfft~(after researching a bit, the way i was thinking of doing it was to model after the phase-vocoder-tutorial part 1 where they use the regular fft~ object, but do it within a pfft~ and then only use the fftout~ part of pfft~, but in order to do this, you'd have to switch the phase of the fftout~ 180º from fft~, and it appears things have been altered around Max6 so that we can't mix and match techniques like that(you either have to use all pfft~(with fftin~/fftout~ within it, and these automatically take care of the phase-switch, windowing, and sync for you) or you do martin's way with fft~/ifft~, but PD objects have a different method of control which is hard to replicate in Max, i'll explain further below...)

some things i changed about martin's math: 
-he had two separate noise~ sources(and i don't think this was correct: because he had one of them going into [-~ 0.25]->[cos~] and the other just to [cos~], if you send the same noise~ source through both, you have the same signal phase-shifted by 90º(one going through sine and the other through cosine; this is known as a signal in 'quadrature'....i am also not completely fresh on this stuff, coming back to max after a 2 year-hiatus, so i could be wrong... but some of it is coming back to me...)... in any case, i definitely don't think having two separate noise sources and one going into [-~ 0.25] would be correct/necessary because it's noise~ and if you have two separate noise~ objects, they will have completely different outputs and there's no reason to subtract [-~ 0.25] from one to turn it into the sine equivalent in that case(hope y'all follow me, i doubt i'm explaining this well, but i'm pretty sure of this). whereas, if you have one noise~ source feeding both routes, then it will create the sine version of the cos~ in that manner properly.
-another thing is he was multiplying by 3, then dividing by 2 in one place, i just changed this to a multiply by 1.5 since that's the same thing, and then in that same area, he was doing a signal-divide(/~) which is more expensive than a multiply(*~), so i inverted the divisor there to turn it into a coefficient by which to multiply and use *~ instead

explanation of the PD objects:
-block~ : this object, as you know is blocking out the vector-size differently in the subpatch from the rest of PD(which is normally 64), but it also has the option for 'overlap' which is shown in the PD patch by '4' as an argument(this is important for FFT).
-bang~ : you already know this, but just to be thorough, bang~ will bang at the beginning of each vector according to the block/vector-size within that subpatch. we can think of the PD subpatch as a dedicated subpatcher for fft~ processing only, so the bang~ helps to synchronize feeding the rfft~ object with a block full of audio(along with a properly synced accompanying hanning window)
-tabread4~ : this is the playback mechanism for the audio-input to rfft~, it's just a sample-playback object which incorporates some kind of interpolation
-tabwrite~ : it isn't shown in your patch pic above, but when i looked at the PD patch, there's a window next to it which shows the hanning window written into an array using this object
-tabreceive~ : this object automatically reads through the array written into by tabwrite~ and is automagically synchronized to the block
-table : the table object labeled, "$0-hann" is the same table which 'tabwrite~ $0-hann' writes into when the patch first starts up, and is the same table from which 'tabreceive~ $0-hann' reads the hanning window synchronized to the processing of the samples of the subpatch's vector/block
(tabreceive~ is actually a really cool feature of PD, automatically synchronizing readout of an array with the processing of samples according to it's local block~'s size/overlap/etc.)

long story short: my pfft~ here (called "SmallMaul" 😋) is not a correct approximation, but it might help see how some things work(i'm just going by the basic idea of disregarding phase, using only the amplitude of each frequency bin, and then throwing noise into the mix especially on the phases... and i believe it's not even phase or amplitude that he is working on but simply real/imaginary(you need to translate to amp/phase using cartopol~ or do more complex math). basically, in trying it out, i was wrong: and you should probably try to do this with fft~ and ifft~ objects(don't use pfft~.... and by the way, poly~ won't help anything here in terms of the fft-processing itself, if you want to add it later to save CPU overall that's fine but it isn't necessary for the patch to work in Max, you can simply synchronize everything with count~ the way the phase-vocoder tutorials do before the whole fft-processing part). unfortunately, using fft~ and ifft~ is a bit more complex, but that's probably a good thing because this form of complexity will match closer to the original PD patch. 

anyways, i doubt anything i wrote made sense, but i tried my best 😆 (i'm terrible at explaining FFT... and to be honest, as i learn it better and better, i'm realizing, i probably don't want to get good at explaining it(lest i were to get paid specifically and handsomely for that 😂), because it is a great deal of work to comprehend let alone explain... my humblest apologies for falling short there).

if you're not trying this anymore, no worries, i just didn't want you to go away completely empty-handed.
hope it helps even if just a little :) best of luck, and sorry again i couldn't be of better assistance ✌️

Raja, wow! Thanks for your input and contribution. Ok this patch may not be what I originally wanted but it's a bloody great start and your explanation is great imo, even for a FFT n00b like myself, I was able to get my head around some of the technicals.

I will pick apart this patch, try out some ideas acquired through some of the tutorials you linked in your previous posts and see what kind of weird sound toy I may come up with, I'm sure it will take me along a different direction I wasn't expecting myself to take, like all experiments!

Thanks again Raja, you're an absolute diamond geeza!

raja_the_font_scrambler.jpg

yo, i'm wondering if something could be done with the fftin~ nofft to replicate tabreceive~ ; and if maybe vectral~ could be of help here

Also when i downloaded the pd patch from Martin's website, there is no samphold~ anymore in the abs_small_paul abstraction. Where did you get your version, Fora ?

I found a few useful conversions in this post linked below

https://cycling74.com/forums/conversion-in-maxmsp

https://cycling74.com/forums/conversion-in-maxmsp 

> samphold~

does pd:wrap~ work for negative numbers, and if yes, what does it it do? i might have a replacement.

I believe it works for negative numbers. wrap~ can be replaced with [%~ 1.]

I came across wrap~ in the post I linked just above.

from PD, wrap~ is explained as follows; Remainder modulo 1

'[wrap~] gives the difference between the input and the largest integer not exceeding it (for positive numbers this is the fractional part)'

from PD, wrap~ is explained as follows; Remainder modulo 1 

that is somehow contradictory, because % does not not work for negative numbers. :)

expr ((($f1-int($f1/$f2)*$f2) + ($f2)*(($f1-int($f1/$f2)*$f2)==0))*($f1>=0)) + ((((($f1-int($f1/$f2)*$f2)+$f2) + (-$f2)*((($f1-int($f1/$f2)*$f2)+$f2)==0))*($f1<0)))

but somehow i am afraid there is a simpler way (like some "wrap" external?)

 I believe it works for negative numbers. wrap~ can be replaced with [%~ 1.] 

not sure what version of Max it didn't work in, but these days % does work on negative numbers(returning the negative modulo/fraction, if you want it to remain positive, you could just abs the output according to when the input is negative), you just have to give it a floating-point argument '1.', and the signal version works too(even if you give it integer argument of '1')

does it look like that on your comp? for some reason it looks normal font(no italics) on mine. i wonder if maybe i accidentally mixed the old Max4.6 PVOC tutorial patch with Max8 and maybe it causes that to happen? (can't think of what else would cause that)

possibly, i was looking at that, too, but couldn't see how it might help. would be worth looking into.

haha, i hadn't heard this term before, had to look it up.. Thanks! 😁 (glad if it could help in any way)

haha, does it look like that on your comp? for some reason it looks normal font(no italics) on mine. i wonder if maybe i accidentally mixed the old Max4.6 PVOC tutorial patch with Max8 and maybe it causes that to happen? (can't think of what else would cause that)

negative numbers on modulo result in negaitive results, which is the correct result, but not what you would exspect from wrapping a range.

(the fonts of Raja's patch appear normal on my machine)

(@Fora i meant, where did you get your PD patch version ? ;) )

re:vectral~, after looking into it slightly further, there is the problem that in pd the pitch change is done in time domain - via reading more or less of the original sound during one frame, so changing playback speed - not spectral domain, so one frame of signal will be repitched *before* there is an fft on it. BUT it is also windowed when it is pitched in this time domain, and not yet fft'ed. So vectral~ couldn't have an use for this problem, only something like "manual" windowing and fft'ing could help, as Raja already suggested... vectral~ could maybe potentially have a use though, if there is a way to change the pitch in fft domain, by "switching" bin's amplitudes - or there is the gizmo~ external, maybe that's how it works, i don't know ; but that wouldn't sound the same surely ?

Then, there is that PD can change windowing block size very conveniently, which you can't do in Max (one needs to recreate the object and give a new arg to change fft/windowing size whereas in PD, you can pass a message to block~). Soooo, er, as Raja said, that's, complicated :p and borderline impossible to obtain exactly the same result as in PureData in as much elegant way (copying abstraction with fft~ and manual windowing for each possible vector size to choose from, or script recreating the fft objects with new frame size each time it's changed are possible options....)

(the fonts of Raja's patch appear normal on my machine)
(@Fora i meant, where did you get your PD patch version ? ;) )
re:vectral~, after looking into it slightly further, there is the problem that in pd the pitch change is done in time domain - via reading more or less of the original sound during one frame, so changing playback speed - not spectral domain, so one frame of signal will be repitched *before* there is an fft on it. BUT it is also windowed when it is pitched in this time domain, and not yet fft'ed. So vectral~ couldn't have an use for this problem, only something like "manual" windowing and fft'ing could help, as Raja already suggested... vectral~ could maybe potentially have a use though, if there is a way to change the pitch in fft domain, by "switching" bin's amplitudes - or there is the gizmo~ external, maybe that's how it works, i don't know ; but that wouldn't sound the same surely ?
Then, there is that PD can change windowing block size very conveniently, which you can't do in Max (one needs to recreate the object and give a new arg to change fft/windowing size whereas in PD, you can pass a message to block~). Soooo, er, as Raja said, that's, complicated :p and borderline impossible to obtain exactly the same result as in PureData in as much elegant way (copying abstraction with fft~ and manual windowing for each possible vector size to choose from, or script recreating the fft objects with new frame size each time it's changed are possible options....)

Oh, the patch is a slight reworking by derek xkwan and the abbstraction is found here..

https://github.com/derekxkwan/pdkvabs/blob/master/dkpaulstretch%7E.pd

No problem, let me know how you get on, I have put this idea on hold for the time being but I will defo keep tags on this thread

Pure Data [bang~] equivalent