James Corley

So for the last few days I've been trying to debug an issue in the Shaper.amxd M4L device. This is the issue:

Occassionally - sometimes constantly - some or all Shaper devices in a live set will lock their values at the first breakpoint. Note: this is not due to me selecting the breakpoint as a sustain point, but it acts as if I have. 

This only happens when the device is in sync mode and when the transport is playing.

Upon opening the broken device in Max with preview mode on, the issue disappears, so the only way to debug is to open a device in Max to start, and then wait until the value gets randomly locked.

Once I am in Max I noticed that the signal leaving the [curve~] object was stuck at the first value. The curve~ object just receives a list from the timescale patcher, which seems to just scale the duration of the envelope data to fit the time period.

My thinking is that the function object is being triggered far too fast and is outputting it's list so fast that it locks the output to the first value, and I may have narrowed it down to why:

The timing is driven by a phasor~ object, which outputs a synced phasor output into a change~ object, which I beleive outputs a different value depending on whether the phasor is rising or falling. So when the phasor signal moves from 1 to 0, that change is tracked, and through the edge~ object is transformed into a bang, thus triggering the function.

The change~ object may be the cause of this issue - the signal entering change~ is to my knowledge an ordinary phase signal synced to live transport, but when this issue happens, it seems the change~ object starts randomly tracking changes in rises and falls, with the maths and edge~ objects then tracking that and causing this bug.

I have tried to fix the issue by using the detect edge patch in the max phasor~ help patch, but this caused other issues, and I have tried to rebuild the device using plugsync~ as a timing system, but I havent made much progress there and it just would break my live sets which use shaper.

Any help from anyone here? Maybe the developer of the device is on the forums, because the more shaper devices I use in my live sets, the worse the issue gets (maybe its a rogue send-receive pair? I havent found any though) and its getting quite infuriating.

Occassionally - sometimes constantly - some or all Shaper devices in a live set will lock their values at the first breakpoint. Note: this is not due to me selecting the breakpoint as a sustain point, but it acts as if I have. 
This only happens when the device is in sync mode and when the transport is playing.
Upon opening the broken device in Max with preview mode on, the issue disappears, so the only way to debug is to open a device in Max to start, and then wait until the value gets randomly locked.
Once I am in Max I noticed that the signal leaving the [curve~] object was stuck at the first value. The curve~ object just receives a list from the timescale patcher, which seems to just scale the duration of the envelope data to fit the time period.
My thinking is that the function object is being triggered far too fast and is outputting it's list so fast that it locks the output to the first value, and I may have narrowed it down to why:

The timing is driven by a phasor~ object, which outputs a synced phasor output into a change~ object, which I beleive outputs a different value depending on whether the phasor is rising or falling. So when the phasor signal moves from 1 to 0, that change is tracked, and through the edge~ object is transformed into a bang, thus triggering the function.
The change~ object may be the cause of this issue - the signal entering change~ is to my knowledge an ordinary phase signal synced to live transport, but when this issue happens, it seems the change~ object starts randomly tracking changes in rises and falls, with the maths and edge~ objects then tracking that and causing this bug.

Hi,
So for the last few days I've been trying to debug an issue in the Shaper.amxd M4L device. This is the issue:
Occassionally - sometimes 

possible-bug-with-change~-shaper-amxd-trying-to-debug

the bug was not change~, but change~ was reporting very weird changes in direction. The phasor~ output did not show anything strange on the signal debug scope, but DID show some odd glitches using the scope~ object. The phasor object was configured with @lock 1, so I tried to find out what that meant, and found nothing. So I removed the lock attribute, and then success.

Time will tell if this was an effective fix, but maybe someone here could explain what @lock actually does and why it may have been in the patch in the first place? The phasor~ has its rate changed with messages, so I’m unsure why locking the frequency actually helps?

the bug was not change~, but change~ was reporting very weird changes in direction. The phasor~ output did not show anything strange on the signal debug scope, but DID show some odd glitches using the scope~ object. The phasor object was configured with @lock 1, so I tried to find out what that meant, and found nothing. So I removed the lock attribute, and then success. 

Possible bug with change~? (Shaper.amxd - trying to debug)