anonymous

The only way to find a bug, is to look at the patch, even for the most 

The only way to find a bug, is to look at the patch, even for the most 
experienced Maxers...

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


poly-problem-4

> I wish it were a bug in my patch but I can assure you it isn't.

Could you give one single reason why you would put a bpatcher into a 

poly~? I can think about it as much I want, but can't find a reason...

A bpatcher you would need for a user interface, a poly~ is always 

closed, to look inside you need to double click/open it. You can do that 

I can assure you, in 98% of all cases when I was sure there is no bug in 

Nobody will look at it if there is no example, its just too unlikely 

Gary schrieb:
> I wish it were a bug in my patch but I can assure you it isn't.

Could you give one single reason why you would put a bpatcher into a 
poly~? I can think about it as much I want, but can't find a reason...

A bpatcher you would need for a user interface, a poly~ is always 
closed, to look inside you need to double click/open it. You can do that 
with normal patchers as well...

No matter if there is a bug in Max...
I can assure you, in 98% of all cases when I was sure there is no bug in 
my patch, there was...
Nobody will look at it if there is no example, its just too unlikely 
that its not worth it...

Quote: Gary wrote on Fri, 09 March 2007 12:50

----------------------------------------------------

what stefan wanted to say is that if you dont post your 

patch to the forum, noone will be able to help with it.

Quote: Gary wrote on Fri, 09 March 2007 12:50
----------------------------------------------------
> I wish it were a bug in my patch but I can assure you it isn't.

what stefan wanted to say is that if you dont post your 
patch to the forum, noone will be able to help with it.

Quote: Gary wrote on Wed, 14 March 2007 16:23

> The poly~ object is to allow polyphonic use of a synth 

> patch while the bpatcher object inside contains various 

> different waveform sources ranging from sine waves to 

it is true that it is possible to open a poly~ window

and edit GUi stuff in it, but eventually it is a good 

idea to have the bpatcher outside of the poly.

(or the poly~ outside of the subpatch where you GUI stuff 

thats probably only a question of personal patching style,

but i strictly seperate GUI/control stuff from DSP.

Quote: Gary wrote on Wed, 14 March 2007 16:23
----------------------------------------------------
> Hello Stefan,
>
> The poly~ object is to allow polyphonic use of a synth 
> patch while the bpatcher object inside contains various 
> different waveform sources ranging from sine waves to 
> complex recorded waves.

it is true that it is possible to open a poly~ window
and edit GUi stuff in it, but eventually it is a good 
idea to have the bpatcher outside of the poly.
(or the poly~ outside of the subpatch where you GUI stuff 
is in).

thats probably only a question of personal patching style,
but i strictly seperate GUI/control stuff from DSP.

> The poly~ object is to allow polyphonic use of a synth patch while 

> the bpatcher object inside contains various different waveform 

> sources ranging from sine waves to complex recorded waves. A 

> drop-down menu selects the wave type and dynamically reloads the 

> appropriate patch into the bpatcher. If I didn't use the bpatcher 

> object for this I would have to have all the different wave types in 

> the poly~ object which would be more CPU intensive (particularly when

This all doesn't force you to use a bpatcher at all, the menu can be

outside of the patcher (non bpatcher), and there is absolutely no need

> I could ofcourse use one wave~ object and reload the waveforms (incl.

> sinewaves, squarewaves, etc) into that but I didn't. Another way

> would be to use scripting to create all the workings of each waveform

You just need a set message to the wave~ object to change the reference 

of the waveform buffer~ (which could be outside of the poly~) No need to 

(scripting during instanciation is fine by the way...)

> The idea of using the poly~ object is to allow for polyphony without 

> having to write my own patch. As it is I have now discarded the 

> poly~ object and just decided to create a number of instances of my 

> synth patch with gates to control the polyphony.

I think you can safely go back to your poly~ construct, just avoid the 

dynamic loading inside. I suspect by the way that your problems is much 

more likely related to the "dynamic loading" part than to the use of the 

Gary schrieb:
> Hello Stefan,
>
> The poly~ object is to allow polyphonic use of a synth patch while 
> the bpatcher object inside contains various different waveform 
> sources ranging from sine waves to complex recorded waves. A 
> drop-down menu selects the wave type and dynamically reloads the 
> appropriate patch into the bpatcher.  If I didn't use the bpatcher 
> object for this I would have to have all the different wave types in 
> the poly~ object which would be more CPU intensive (particularly when
>  multiplied by many poly~ instances).

This all doesn't force you to use a bpatcher at all, the menu can be
outside of the patcher (non bpatcher), and there is absolutely no need
to dynamically reload anything.

> I could ofcourse use one wave~ object and reload the waveforms (incl.
> sinewaves, squarewaves, etc) into that but I didn't. Another way
> would be to use scripting to create all the workings of each waveform
> subpatch (but what a pain).

You just need a set message to the wave~ object to change the reference 
of the waveform buffer~ (which could be outside of the poly~) No need to 
script or reload anything...
(scripting during instanciation is fine by the way...)

> The idea of using the poly~ object is to allow for polyphony without 
> having to write my own patch.  As it is I have now discarded the 
> poly~ object and just decided to create a number of instances of my 
> synth patch with gates to control the polyphony.

I think you can safely go back to your poly~ construct, just avoid the 
dynamic loading inside. I suspect by the way that your problems is much 
more likely related to the "dynamic loading" part than to the use of the 
bpatcher...

Poly~ problem