Unusual behaviour of dot.aggregate.leaky.maxpat

32 views
Skip to first unread message

d.andrew STEWART

unread,
Jan 8, 2025, 1:28:54 PMJan 8
to dot_mapper
Here is an odd situation I've just experienced. Any thoughts would be appreciated. More like the Twilight Zone or alternate universe......

The other day, I had unusual behaviour of the DOT's leaky integrator patch [dot.aggregate.leaky]. In one Max patch, I use three instances of [dot.aggregate.leaky], each with their own argument values, but each receiving `exactly` the same input – I was sending the exact same value (from one axis of an accelerometer) to the three instances of [dot.aggregate.leaky], using a DMI (karlax).

The unusual behaviour:

On one occasion, one of the three [dot.aggregate.leaky] worked as expected, while the other two instances only produced a maximum value of 1.0. On another occasion, after re-starting the patch, the situation was reversed. The first instance of [dot.aggregate.leaky] would do nothing except send out 1.0 and the other two worked fine.

I'm sorry if this sounds confusing.....believe, after years of working with the same Max patch and [dot.aggregate.leaky], I was also confused and didn't know what to do.

Of course, I re-instantiated the objects in my Max patch. Sometimes this worked if, for example, I literally converted the object into some other Max external and then, re-created it as [dot.aggregate.leaky]. I also inputted the same argument values into all of the [dot.aggregate.leaky] and still, only one would work, while the others output 1.0.

I also quitted and restarted Max, and my DMI (karlax) numerous times, thinking it may have something to do with other data transmission issues, even if the Max application showed no evidence of this.

The SOLUTION: (and here's where it becomes even more confusing)


-Use a different USB C to USB adapter (WTF)


You see, the only recent change I have made is the way I have been connecting the karlax receiver to my computer. I started using a single port USB C to USB adapter instead of a multi-port/hub SATECHI adapter. I can systematically recreate the error with [dot.aggregate.leaky] by using the single port USB C to USB adapter, while the SATECHI leads to perfect functioning of the Max patch......what the hell is going on with Max, which seems to be impacted by which USB adapter I use.  Never seen this before......


Screenshot 2025-01-08 at 11.22.03.png



d.andrew STEWART

unread,
Jan 9, 2025, 12:55:31 AMJan 9
to dot_mapper
While it seemed that using a specific USB C to USB adapter was the solution, sadly, this wasn't the case. I can now report that [dot.aggregate.leaky] is still not problematic.  I have no explanation for why [dot.aggregate.leaky] is no longer functioning in a stable way.

When the Max patch launches, specific values are sent to each [dot.aggregate.leaky], initialising the subpatch for my needs. It's as if [dot.aggregate.leaky] is no longer initialising correctly at start-up.

I have tried delaying the transmission of these values, considering that my complex patch needs a moment to load, but the delay does not help.

Sometimes – and only sometimes, if I manually increase the value into the 2nd inlet (i.e., leak speed), [dot.aggregate.leaky]  seems to reset itself, but not always.

My next attempt to fix this may be to programme my patch with the contents of [dot.aggregate.leaky], instead of "calling" it in as an abstraction.

Thoughts?

Joseph Malloch

unread,
Jan 9, 2025, 10:09:30 AMJan 9
to dot_m...@googlegroups.com
Hi Andrew,

I should have some time tomorrow to investigate and fix this. 

Could you send me a copy of the misbehaving patch? And if possible some of the data you are sending through the patch?

[dot.aggregate.leaky] is a weird abstraction since it uses patcher scripting to dynamically set the leak expression. If you open and save the abstraction perhaps some scripted objects were accidentally saved – though if working properly they should be automatically deleted. For this reason, could you also attach a copy of your dot.aggregate.leaky.maxpat?

Thanks,
Joe
–––
Joseph Malloch, PhD
Assistant Professor
Graphics and Experiential Media Lab,
Faculty of Computer Science, Dalhousie University


On Jan 9, 2025, at 01:55, d.andrew STEWART <dandrew...@gmail.com> wrote:

While it seemed that using a specific USB C to USB adapter was the solution, sadly, this wasn't the case. I can now report that [dot.aggregate.leaky] is still not problematic.  I have no explanation for why [dot.aggregate.leaky] is no longer functioning in a stable way.
--
You received this message because you are subscribed to the Google Groups "dot_mapper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dot_mapper+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dot_mapper/1f01194a-f1c0-4704-b839-0a0bbedfb593n%40googlegroups.com.

d.andrew STEWART

unread,
Jan 10, 2025, 11:56:05 AMJan 10
to dot_mapper
Thanks, much, if you have time for this. I have not sent my entire Karlax patch; instead, I extracted one of the subpatches that contains three [dot.aggregate.leaky]. I have also included a copy of [dot.aggregate.leaky] from the Max Package installation of DOT.  If, on the other hand, you need to see the entire Karlax patch, let me know. I use [dot.aggregate.leaky] all over the place!


I've just realised, you might want to see the values I use to initialise these three [dot.aggregate.leaky] at start-up. I have the data stored in [coll] format:

7, 4.4 0.25 30. init_shake_up_quick;
8, 0.617 0.1 40. init_shake_up_moderate;
9, 0.3338 0.0666 100. init_shake_up_long;

All the best

d.andrew STEWART

unread,
Jan 10, 2025, 11:58:36 AMJan 10
to dot_mapper
In addition,  I wanted to indicate that I am sending acceleromater data that is scalsed to values between 0.0 and 1.0.  So, if you simulat incoming accel. data, contrain to this range of values

Joseph Malloch

unread,
Jan 11, 2025, 9:10:13 AMJan 11
to dot_m...@googlegroups.com

d.andrew STEWART

unread,
Jan 11, 2025, 7:42:26 PMJan 11
to dot_mapper
Thanks a bunch Joe.  So far, so good. The newer version of [dot.aggregate.leaky] working well. Maybe it's a coincidence, but with this new version, each time I launch mapperGUI from source, Chrome browser also draws all of the controls correctly - no need to tweak CSS, but I'll keep you posted on this behaviour.
Reply all
Reply to author
Forward
0 new messages