Vlad Spears

no-plug-love-with-transposer

Oops, forgot my info... I'm on a MacBook Pro, 2.16GHz, 2GB, 10.4.9, 

latest versions of Max/MSP 4.6.3 and Pluggo 3.6.1. I haven't tried 

Oops, forgot my info... I'm on a MacBook Pro, 2.16GHz, 2GB, 10.4.9,  
latest versions of Max/MSP 4.6.3 and Pluggo 3.6.1.  I haven't tried  
it in XP yet.

http://www.daevlmakr.com
http://www.2secondfuse.com

On 5 juin 07, at 09:59, Vlad Spears wrote:

> I'm trying to work around a bug when using [pfft~] in the Pluggo 

> environment, so I sadly need to replace [gizmo~] functionality 

> using the [transposer] subpatch from pitchshifting-playground.pat 

hipno plug-ins use gizmo~ and pfft~ objects, so the problem is 

> I've taken [transposer] directly from pitchshifting-playground and 

> plunked it into a plug-in. From what I can see, [transposer] 

> should already be set up to function in a plug-in perfectly... 

> whoever created it even used the Pluggo auto-exclusive naming 

> convention of "---" on the objects that need it. (Les? It looks 

> Here's the patch, taken directly from pitchshifting-playground. 

> I've de-encapsulated it to see the workings, only adding [meter~] 

> in a few places to find where the signal flow stops once it's 

> exported as a plug-in. While this patch works fine in Max, as a 

> plug-in the [cycle~] objects appear not to be cycling.

There's no pp objects in your patch, is it normal? On my computer 

(PPC, MaxMSP 4.6.3, pluggo 3.6.1), I can build the plug-in and use it 

> Can someone please verify this and/or tell me what I'm blindly 

> missing here? It seems like such a simple patch! You'll have to 

Not if you choose the New from clipboard option from the file menu 

(It'll disable the loadbang if you use the shortcut from the ejies 

> I'm trying to work around a bug when using [pfft~] in the Pluggo  
> environment, so I sadly need to replace [gizmo~] functionality  
> using the [transposer] subpatch from pitchshifting-playground.pat  
> in /examples... but it's not working.

hipno plug-ins use gizmo~ and pfft~ objects, so the problem is  
elsewhere.

> I've taken [transposer] directly from pitchshifting-playground and  
> plunked it into a plug-in.  From what I can see, [transposer]  
> should already be set up to function in a plug-in perfectly...  
> whoever created it even used the Pluggo auto-exclusive naming  
> convention of "---" on the objects that need it.  (Les?  It looks  
> like his patching style.)
>
> Here's the patch, taken directly from pitchshifting-playground.   
> I've de-encapsulated it to see the workings, only adding [meter~]  
> in a few places to find where the signal flow stops once it's  
> exported as a plug-in.  While this patch works fine in Max, as a  
> plug-in the [cycle~] objects appear not to be cycling.

There's no pp objects in your patch, is it normal? On my computer  
(PPC, MaxMSP 4.6.3, pluggo 3.6.1), I can build the plug-in and use it  
inside the vst~ object.

> Can someone please verify this and/or tell me what I'm blindly  
> missing here?  It seems like such a simple patch!  You'll have to  
> save and re-open to get the loadbangs.

Not if you choose the New from clipboard option from the file menu  
(It'll disable the loadbang if you use the shortcut from the ejies  
though...).

On Jun 5, 2007, at 1:33 AM, Emmanuel Jourdan replied:

>> I'm trying to work around a bug when using [pfft~] in the Pluggo 

>> environment, so I sadly need to replace [gizmo~] functionality 

>> using the [transposer] subpatch from pitchshifting-playground.pat 

> hipno plug-ins use gizmo~ and pfft~ objects, so the problem is 

EJ, are you trying to tell me Hipno can't have any bugs? ;) This is a 

different topic than the one above, but I submitted this as a bug 

report to Cycling support already, though I haven't head back yet. 

Here's what I wrote in my email to Support:

I've found what I think is a problem with [pfft~] when used in 

multiple Pluggos. It was first noticed by a beta tester of my own 

set of plug-ins. I narrowed the problem down to plug-ins using 

[pfft~]. I've now found it in Cycling's own Spectral Filter Pluggo, 

based on the Forbidden Planet patch, which also uses [pfft~].

Multiple Pluggos using [pfft~] can cause high frequency distortion to 

Open a new document in Live. Drop a sound file on the first two 

channels. On each channel, place an instance of Pluggo's Spectral 

Filter. Play the clips in both channels simultaneously.

Playing with both instances of Spectral Filter on usually produces a 

glitchy, high frequency distortion in the sound. Turning one 

instance off eliminates the glitch. Turning the instance back on 

will sometimes immediately return the glitch, other times it will 

take some minutes before it returns. Switching the plug-ins on and 

off a few times will cause the problem to show up faster.

Live 6.0.7 under 10.4.9 on a MacBook Pro, 2.16GHz, 2GB RAM, Pluggo 3.6.1

ProTools M-Powered 7.3.1 under 10.4.8 and 10.4.9 on a MacBook Pro, 

I've placed a 3.57MB zip with examples waves of clean sound and 

http://www.2secondfuse.com/sekret/pfft_bug_waves.zip

Also, I've found a mention of something that sounds like this problem 

in the forum, from mid-November of 2006, but there were no replies-

t=tree&th=22888&rid=0&S=290cb594cdf98be4179a3535d5205c08

Segeke was running a PowerMac G5 Dual 2.5GHz with Pluggo Runtime 3.6, 

>> I've taken [transposer] directly from pitchshifting-playground and 

>> plunked it into a plug-in. From what I can see, [transposer] 

>> should already be set up to function in a plug-in perfectly... 

>> whoever created it even used the Pluggo auto-exclusive naming 

>> convention of "---" on the objects that need it. (Les? It looks 

>> Here's the patch, taken directly from pitchshifting-playground. 

>> I've de-encapsulated it to see the workings, only adding [meter~] 

>> in a few places to find where the signal flow stops once it's 

>> exported as a plug-in. While this patch works fine in Max, as a 

>> plug-in the [cycle~] objects appear not to be cycling.

> There's no pp objects in your patch, is it normal? On my computer 

> (PPC, MaxMSP 4.6.3, pluggo 3.6.1), I can build the plug-in and use 

I don't usually place any [pp]s when I'm developing a plug-in until I 

need to start saving state. This is just a patch to test out 

[transposer] and find out why it doesn't work as a plug-in.

It does work in [vst~] for me, but not in Live 6.0.7. That's pretty 

>> Can someone please verify this and/or tell me what I'm blindly 

>> missing here? It seems like such a simple patch! You'll have to 

>> save and re-open to get the loadbangs.

> Not if you choose the New from clipboard option from the file menu 

> (It'll disable the loadbang if you use the shortcut from the ejies 

Thanks for reminding me of that! I've become so dependent on your 

>> I'm trying to work around a bug when using [pfft~] in the Pluggo  
>> environment, so I sadly need to replace [gizmo~] functionality  
>> using the [transposer] subpatch from pitchshifting-playground.pat  
>> in /examples... but it's not working.
>
> hipno plug-ins use gizmo~ and pfft~ objects, so the problem is  
> elsewhere.

EJ, are you trying to tell me Hipno can't have any bugs? ;) This is a  
different topic than the one above, but I submitted this as a bug  
report to Cycling support already, though I haven't head back yet.  
Here's what I wrote in my email to Support:

I've found what I think is a problem with [pfft~] when used in  
multiple Pluggos.  It was first noticed by a beta tester of my own  
set of plug-ins.  I narrowed the problem down to plug-ins using  
[pfft~].  I've now found it in Cycling's own Spectral Filter Pluggo,  
based on the Forbidden Planet patch, which also uses [pfft~].

Summary:
Multiple Pluggos using [pfft~] can cause high frequency distortion to  
appear.

Steps to Reproduce:
Open a new document in Live.  Drop a sound file on the first two  
channels.  On each channel, place an instance of Pluggo's Spectral  
Filter.  Play the clips in both channels simultaneously.

Actual Results:
Playing with both instances of Spectral Filter on usually produces a  
glitchy, high frequency distortion in the sound.  Turning one  
instance off eliminates the glitch.  Turning the instance back on  
will sometimes immediately return the glitch, other times it will  
take some minutes before it returns.  Switching the plug-ins on and  
off a few times will cause the problem to show up faster.

Regression:
Live 6.0.7 under 10.4.9 on a MacBook Pro, 2.16GHz, 2GB RAM, Pluggo 3.6.1
ProTools M-Powered 7.3.1 under 10.4.8 and 10.4.9 on a MacBook Pro,  
2.0GHz, 2GB RAM, Pluggo Runtime 3.6.1

Notes:
I've placed a 3.57MB zip with examples waves of clean sound and  
bugged sound here-
http://www.2secondfuse.com/sekret/pfft_bug_waves.zip

Also, I've found a mention of something that sounds like this problem  
in the forum, from mid-November of 2006, but there were no replies-
https://cycling74.com/forums/index.php? 
t=tree&th=22888&rid=0&S=290cb594cdf98be4179a3535d5205c08
Segeke was running a PowerMac G5 Dual 2.5GHz with Pluggo Runtime 3.6,  
so it's not just an Intel problem.

>> I've taken [transposer] directly from pitchshifting-playground and  
>> plunked it into a plug-in.  From what I can see, [transposer]  
>> should already be set up to function in a plug-in perfectly...  
>> whoever created it even used the Pluggo auto-exclusive naming  
>> convention of "---" on the objects that need it.  (Les?  It looks  
>> like his patching style.)
>>
>> Here's the patch, taken directly from pitchshifting-playground.   
>> I've de-encapsulated it to see the workings, only adding [meter~]  
>> in a few places to find where the signal flow stops once it's  
>> exported as a plug-in.  While this patch works fine in Max, as a  
>> plug-in the [cycle~] objects appear not to be cycling.
>
> There's no pp objects in your patch, is it normal? On my computer  
> (PPC, MaxMSP 4.6.3, pluggo 3.6.1), I can build the plug-in and use  
> it inside the vst~ object.

I don't usually place any [pp]s when I'm developing a plug-in until I  
need to start saving state.  This is just a patch to test out  
[transposer] and find out why it doesn't work as a plug-in.

It does work in [vst~] for me, but not in Live 6.0.7.  That's pretty  
funky.

>> Can someone please verify this and/or tell me what I'm blindly  
>> missing here?  It seems like such a simple patch!  You'll have to  
>> save and re-open to get the loadbangs.
>
> Not if you choose the New from clipboard option from the file menu  
> (It'll disable the loadbang if you use the shortcut from the ejies  
> though...).

Thanks for reminding me of that!  I've become so dependent on your  
shift-command-N shortcut that I forgot!

>Can someone please verify this and/or tell me what I'm blindly 

>missing here? It seems like such a simple patch! You'll have to 

If it's any consolation, I can reproduce the behavior you describe - 

works fine in a Max patch, but not as a Pluggo (in Live on a Mac). 

And I too can't easily see why it's not working there.

FWIW, in my experience I've found that transposer abstraction to be 

somewhat flaky, even in the Max environment; sometimes it works for 

me, sometimes not. Again, not sure as to the cause...

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

>Can someone please verify this and/or tell me what I'm blindly 
>missing here?  It seems like such a simple patch!  You'll have to 
>save and re-open to get the loadbangs.

If it's any consolation, I can reproduce the behavior you describe - 
works fine in a Max patch, but not as a Pluggo (in Live on a Mac). 
And I too can't easily see why it's not working there.

FWIW, in my experience I've found that transposer abstraction to be 
somewhat flaky, even in the Max environment; sometimes it works for 
me, sometimes not.  Again, not sure as to the cause...

Dan
-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


From memory, it's to do with the loadbang sequence and the cycle~ object not getting updated with the whole waveform.

I think you can get it all to work fine if you make sure that the cycle~ objects get a "set ---windo" message after the buffer~ has been filled.

On Jun 5, 2007, at 9:30 AM, Emmanuel Jourdan wrote:

> On 5 juin 07, at 13:43, Dan Nigrin wrote:

>> If it's any consolation, I can reproduce the behavior you describe 

>> - works fine in a Max patch, but not as a Pluggo (in Live on a 

>> Mac). And I too can't easily see why it's not working there.

> Ok I found the problem, it's the cycle~ object which does not find 

> the buffer~. If you send the set message manually after filling the 

> buffer, it does work. Thanks for the report.

Yes, that did it... thanks Emmanuel, Dan and Andrew! Simple... but 

And um... since we did wrap it into this thread: any ideas on the 

[pfft~] issue? I'd *much* prefer to use it and [gizmo~], as it 

sounds far better than [transposer], especially with rhythmic 

> On 5 juin 07, at 13:43, Dan Nigrin wrote:
>
>> If it's any consolation, I can reproduce the behavior you describe  
>> - works fine in a Max patch, but not as a Pluggo (in Live on a  
>> Mac). And I too can't easily see why it's not working there.
>
> Ok I found the problem, it's the cycle~ object which does not find  
> the buffer~. If you send the set message manually after filling the  
> buffer, it does work. Thanks for the report.
>
> ej

Yes, that did it... thanks Emmanuel, Dan and Andrew!  Simple... but  
so not obvious to me.

And um... since we did wrap it into this thread: any ideas on the  
[pfft~] issue?  I'd *much* prefer to use it and [gizmo~], as it  
sounds far better than [transposer], especially with rhythmic  
material, but that bug is ugly.

To revive this old topic, I'm experiencing the same:

https://cycling74.com/forums/index.php?t=msg&th=37891&start=0&rid=7271&S=bb2c6e16754d3904506d86fd7cf5742b

Any ideas for a fix would be very helpful!

no plug love with [transposer]