Forums > MaxMSP

send~/receive~ vs patchcords in pfft~

December 15, 2006 | 2:28 pm

I’ve found that using send~/receive~ objects as opposed to patchords in a
subpatch* for pfft~ regularly caused max to crash. For some reason when I
turned on audio within the patch in which the fft processing was taking
place the dsp menu would register it as off. Further action (like using
audio tester) would cause a crash – sometimes max just crashed anyway. It
seems that some kind of conflict ensues in this case.

With the same subpatch ‘rewired’ with patchcords, no problem!

*
[The subpatch in question simply takes real, imaginary and bin info and
allocates the r/i frequency data to channels using a steam-age system of
comparion operators and gates (e.g. if the bin numbers are within the range
1-2, the data goes through gate1, between 2 and 3, goes through gate2,
etc.).]

It would be useful to be able to use send~/receive~ in this situation since
this makes it much easier to ensure that the right data gets to the right
object and it just looks less cluttered. However, the patchcords don’t cause
a crash! Has anyone else observed this or similar behaviour. Even better,
could anyone explain it?

best,

David

It’s Hotmail’s 10th Birthday! Come and play Pass the Parcel

http://www.msnpasstheparcel.com


December 15, 2006 | 3:51 pm


December 15, 2006 | 4:08 pm

Hello,

David Roden :
> I’ve found that using send~/receive~ objects as opposed to patchords in a
> subpatch* for pfft~ regularly caused max to crash. For some reason when I
> turned on audio within the patch in which the fft processing was taking
> place the dsp menu would register it as off. Further action (like using
> audio tester) would cause a crash – sometimes max just crashed anyway. It
> seems that some kind of conflict ensues in this case.
>
> With the same subpatch ‘rewired’ with patchcords, no problem!

Maybe it’s because send~/receive~ delays the signal by one block (signal vector
size)

Did you try with send/receive instead of send~/receive~ ?


December 15, 2006 | 4:36 pm

On 15-Dec-2006, at 15:28, David Roden wrote:

> I’ve found that using send~/receive~ objects as opposed to
> patchords in a subpatch* for pfft~ regularly caused max to crash.

You wouldn’t happen to be down/upsampling inside the pfft~, would
you? Or anything else affecting your signal vectors?

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


December 17, 2006 | 4:56 pm

julien breval wrote:
> Maybe it’s because send~/receive~ delays the signal by one block
> (signal vector size)

It would only delay it if there is a feddback loop, but its more heavy
on the CPU, as it has to do some checks.

> Did you try with send/receive instead of send~/receive~

That should actually be equivalent to the patch chord. (and more effective)
But if you’d send between inside and outside of a pfft~ I would expect
desaster, nothing is checked, and vector sizes are most likely
different. I would expect it to crash, and it’s probably not worth to
add some protection against "insane" patching. Its better the cycling
folks concentrate on Max 5…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


Viewing 5 posts - 1 through 5 (of 5 total)