joshua goldberg

i just removed two number boxes that were still in my patch from 

debugging two years ago, and my framerate when using external controls 

number boxes kill framerate! this is a reminder from your friendly 

i just removed two number boxes that were still in my patch from  
debugging two years ago, and my framerate when using external controls  
just doubled.

number boxes kill framerate!  this is a reminder from your friendly  
neighborhood goldberg.  that is all.

unbelievable

I wonder if that even affects the speed if the numbers are hidden by the 

jitter window (probably yes?) or are in a closed subpatch (probably no?)

otoh, I can't believe deleting two numberboxes can *double* your 

> i just removed two number boxes that were still in my patch from 

> debugging two years ago, and my framerate when using external controls 

> number boxes kill framerate! this is a reminder from your friendly 

I wonder if that even affects the speed if the numbers are hidden by the 
jitter window (probably yes?) or are in a closed subpatch (probably no?)
do you know anything about that.
otoh, I can't believe deleting two numberboxes can *double* your 
framerate...
marius.

joshua goldberg wrote:
> i just removed two number boxes that were still in my patch from 
> debugging two years ago, and my framerate when using external controls 
> just doubled.
>
> number boxes kill framerate!  this is a reminder from your friendly 
> neighborhood goldberg.  that is all.
>
> j
>


it doesn't matter if the numbers are in hidden subpatches or 

abstractions or whatever. get rid of them and your framerate will 

i had twenty instances of an abstraction with two number boxes that 

framerate during midi input went from 15 to 30.

On Jan 11, 2008, at 9:06 PM, marius schebella wrote:

> I wonder if that even affects the speed if the numbers are hidden by 

> the jitter window (probably yes?) or are in a closed subpatch 

> otoh, I can't believe deleting two numberboxes can *double* your 

>> i just removed two number boxes that were still in my patch from 

>> debugging two years ago, and my framerate when using external 

>> number boxes kill framerate! this is a reminder from your friendly 

it doesn't matter if the numbers are in hidden subpatches or  
abstractions or whatever.  get rid of them and your framerate will  
*soar*.

i had twenty instances of an abstraction with two number boxes that  
were being hit by every midi input.

> I wonder if that even affects the speed if the numbers are hidden by  
> the jitter window (probably yes?) or are in a closed subpatch  
> (probably no?)
> do you know anything about that.
> otoh, I can't believe deleting two numberboxes can *double* your  
> framerate...
> marius.
>
> joshua goldberg wrote:
>> i just removed two number boxes that were still in my patch from  
>> debugging two years ago, and my framerate when using external  
>> controls just doubled.
>> number boxes kill framerate!  this is a reminder from your friendly  
>> neighborhood goldberg.  that is all.
>> j
>
>


what about numbers that are not connected to an outlet. do these also 

> it doesn't matter if the numbers are in hidden subpatches or 

> abstractions or whatever. get rid of them and your framerate will *soar*.

> i had twenty instances of an abstraction with two number boxes that were 

> framerate during midi input went from 15 to 30.

> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:

>> I wonder if that even affects the speed if the numbers are hidden by 

>> the jitter window (probably yes?) or are in a closed subpatch 

>> otoh, I can't believe deleting two numberboxes can *double* your 

>>> i just removed two number boxes that were still in my patch from 

>>> debugging two years ago, and my framerate when using external 

>>> number boxes kill framerate! this is a reminder from your friendly 

what about numbers that are not connected to an outlet. do these also 
cause trouble by getting "refreshed"?
marius.

joshua goldberg wrote:
> it doesn't matter if the numbers are in hidden subpatches or 
> abstractions or whatever.  get rid of them and your framerate will *soar*.
>
> i had twenty instances of an abstraction with two number boxes that were 
> being hit by every midi input.
>
> framerate during midi input went from 15 to 30.
>
>
> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:
>
>> I wonder if that even affects the speed if the numbers are hidden by 
>> the jitter window (probably yes?) or are in a closed subpatch 
>> (probably no?)
>> do you know anything about that.
>> otoh, I can't believe deleting two numberboxes can *double* your 
>> framerate...
>> marius.
>>
>> joshua goldberg wrote:
>>> i just removed two number boxes that were still in my patch from 
>>> debugging two years ago, and my framerate when using external 
>>> controls just doubled.
>>> number boxes kill framerate!  this is a reminder from your friendly 
>>> neighborhood goldberg.  that is all.
>>> j
>>
>>
>
>


On Jan 11, 2008, at 9:36 PM, marius schebella wrote:

> what about numbers that are not connected to an outlet. do these 

> also cause trouble by getting "refreshed"?

>> it doesn't matter if the numbers are in hidden subpatches or 

>> abstractions or whatever. get rid of them and your framerate will 

>> i had twenty instances of an abstraction with two number boxes that 

>> framerate during midi input went from 15 to 30.

>> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:

>>> I wonder if that even affects the speed if the numbers are hidden 

>>> by the jitter window (probably yes?) or are in a closed subpatch 

>>> otoh, I can't believe deleting two numberboxes can *double* your 

>>>> i just removed two number boxes that were still in my patch from 

>>>> debugging two years ago, and my framerate when using external 

>>>> number boxes kill framerate! this is a reminder from your 

>>>> friendly neighborhood goldberg. that is all.

> what about numbers that are not connected to an outlet. do these  
> also cause trouble by getting "refreshed"?
> marius.
>
> joshua goldberg wrote:
>> it doesn't matter if the numbers are in hidden subpatches or  
>> abstractions or whatever.  get rid of them and your framerate will  
>> *soar*.
>> i had twenty instances of an abstraction with two number boxes that  
>> were being hit by every midi input.
>> framerate during midi input went from 15 to 30.
>> On Jan 11, 2008, at 9:06 PM, marius schebella wrote:
>>> I wonder if that even affects the speed if the numbers are hidden  
>>> by the jitter window (probably yes?) or are in a closed subpatch  
>>> (probably no?)
>>> do you know anything about that.
>>> otoh, I can't believe deleting two numberboxes can *double* your  
>>> framerate...
>>> marius.
>>>
>>> joshua goldberg wrote:
>>>> i just removed two number boxes that were still in my patch from  
>>>> debugging two years ago, and my framerate when using external  
>>>> controls just doubled.
>>>> number boxes kill framerate!  this is a reminder from your  
>>>> friendly neighborhood goldberg.  that is all.
>>>> j
>>>
>>>
>


> number boxes kill framerate! this is a reminder from your friendly

I apologize, Joshua. I thought you were full of it. Now this big patch works.

> number boxes kill framerate!  this is a reminder from your friendly
> neighborhood goldberg.  that is all.

I apologize, Joshua.  I thought you were full of it.  Now this big patch works.

The only thing Joshua is full of is THE AWESOME. And uh, the insane 

too... and wait, also LOTS OF CRAZY MANIC ENERGY.

ok he is full of a lot of stuff but not 'it'.

On Jan 12, 2008, at 12:26 AM, keith manlove wrote:

>> number boxes kill framerate! this is a reminder from your friendly

> I apologize, Joshua. I thought you were full of it. Now this big 

The only thing Joshua is full of is THE AWESOME. And uh, the insane  
too... and wait, also LOTS OF CRAZY MANIC ENERGY.

>> number boxes kill framerate!  this is a reminder from your friendly
>> neighborhood goldberg.  that is all.
>
> I apologize, Joshua.  I thought you were full of it.  Now this big  
> patch works.
>
> Keith


number boxes really are a mixed blessing, aren't they? I mean, debugging tool, quick visualizer, and total flow killer, source of endless rounding errors.

I remember trying to make a matrix mixer that had about 100 number boxes going on... then the change of efficiency when I involved jit.cellblock!!! wow.

If I want to have PATTR control of a bunch of variables, what is the best way to implement that. What is the still pattr-able substitute for a number box? 

Simple example would be 10 objects with editable xposition, yposition, xscale, yscale type information for each object that is then saved as presets with pattrstorage. Would Jit.cellblock still allow me to crossfade between presets smoothly?

If I want to have PATTR control of a bunch of variables, what is the best way to implement that.  What is the still pattr-able substitute for a number box? 
Simple example would be 10 objects with editable xposition, yposition, xscale, yscale type information for each object that is then saved as presets with pattrstorage.  Would Jit.cellblock still allow me to crossfade between presets smoothly?


On Jan 12, 2008, at 3:12 PM, Leo Mayberry wrote:

> If I want to have PATTR control of a bunch of variables, what is the 

> best way to implement that. What is the still pattr-able substitute 

> Simple example would be 10 objects with editable xposition, 

> yposition, xscale, yscale type information for each object that is 

> then saved as presets with pattrstorage. Would Jit.cellblock still 

> allow me to crossfade between presets smoothly?

"The greatest of the changes that science has brought us is the acuity 

of change; the greatest novelty the extent of novelty."

>
> If I want to have PATTR control of a bunch of variables, what is the  
> best way to implement that.  What is the still pattr-able substitute  
> for a number box?
> Simple example would be 10 objects with editable xposition,  
> yposition, xscale, yscale type information for each object that is  
> then saved as presets with pattrstorage.  Would Jit.cellblock still  
> allow me to crossfade between presets smoothly?
>

San Francisco, CA
Work: 857-544-3967
Email: bthrew (at) gmail (dot) com
IM: captogreadmore (AIM)
http://www.barrythrew.com

"The greatest of the changes that science has brought us is the acuity  
of change; the greatest novelty the extent of novelty."
- J. Robert Oppenheimer


are there the same issues with prepend set to a message box?

Yes - to some extent. Use v or value, or pattr. Anything with GUI 

On Jan 15, 2008, at 8:23 PM, Parag K Mital wrote:

> are there the same issues with prepend set to a message box?

Yes - to some extent. Use v or value, or pattr. Anything with GUI  
updates, hidden or not = DO NOT WANT.

> are there the same issues with prepend set to a message box?


For some time I have been struggling with Jittery video from

All I wanted to do was to very rapidly playback very short clips (and extract ALPHA) via triggering from GPI, MIDI, or whatever...

When I create my patches I always use KEY object instead of

NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I

dont want to carry MIDI keyboard everywhere while testing

trigger interactivity... so I test interactivity with keyboard input.

Long story short - Qwerty KEYBOARD triggering (via KEY obj) of

clips results in jittery playback... if I replace the KEY

objects with NOTEIN objects... playback is smooth!!!

I guess KEY object screws with scheduler or something...

Yes, yes, yes, I am aware of VADE's recent posts to minimize

jittery playback... tips like QMETRO, UNIQUE, etc...

This most simple patch uses METRO2 and does not use UNIQUE

(unique = message or atttribue (I forget) of Jit.movie.

I will test this further but my point is that triggering clips

via qwerty-keyboard input may be yet another culprit in

I laughed so hard last night...
For some time I have been struggling with Jittery video from
Jitter...

All I wanted to do was to very rapidly playback very short clips (and extract ALPHA) via triggering from GPI, MIDI, or whatever... 

When I create my patches I always use KEY object instead of
NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I
dont want to carry MIDI keyboard everywhere while testing
trigger interactivity... so I test interactivity with keyboard input.

Long story short - Qwerty KEYBOARD triggering (via KEY obj) of
clips results in jittery playback... if I replace the KEY
objects with NOTEIN objects... playback is smooth!!!

I guess KEY object screws with scheduler or something...
much more so than NOTEIN object.

Yes, yes, yes, I am aware of VADE's recent posts to minimize
jittery playback... tips like QMETRO, UNIQUE, etc...
all awesome tips indeed - I use'um :>

This most simple patch uses METRO2 and does not use UNIQUE
(unique = message or atttribue (I forget) of Jit.movie.

I will test this further but my point is that triggering clips
via qwerty-keyboard input may be yet another culprit in
Jittery playback...

Like the existence of any key object is the problem? Interesting, because I always have at least one in there for taking my window output to fullscreen. Or do you specifically mean a key object tied into triggering of quicktime?

Like the existence of any key object is the problem?  Interesting, because I always have at least one in there for taking my window output to fullscreen.  Or do you specifically mean a key object tied into triggering of quicktime?


can you send a very simple patch demonstrating this? because i am 

On Jan 17, 2008, at 3:18 PM, robert vanrhyn wrote:

> For some time I have been struggling with Jittery video from

> All I wanted to do was to very rapidly playback very short clips 

> (and extract ALPHA) via triggering from GPI, MIDI, or whatever...

> When I create my patches I always use KEY object instead of

> NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I

> dont want to carry MIDI keyboard everywhere while testing

> trigger interactivity... so I test interactivity with keyboard input.

> Long story short - Qwerty KEYBOARD triggering (via KEY obj) of

> clips results in jittery playback... if I replace the KEY

> objects with NOTEIN objects... playback is smooth!!!

> I guess KEY object screws with scheduler or something...

> Yes, yes, yes, I am aware of VADE's recent posts to minimize

> jittery playback... tips like QMETRO, UNIQUE, etc...

> This most simple patch uses METRO2 and does not use UNIQUE

> (unique = message or atttribue (I forget) of Jit.movie.

> I will test this further but my point is that triggering clips

> via qwerty-keyboard input may be yet another culprit in

can you send a very simple patch demonstrating this?  because i am  
extremely skeptical.

>
> I laughed so hard last night...
> For some time I have been struggling with Jittery video from
> Jitter...
>
> All I wanted to do was to very rapidly playback very short clips  
> (and extract ALPHA) via triggering from GPI, MIDI, or whatever...
>
> When I create my patches I always use KEY object instead of
> NOTEIN (NOTEIN to be used with GPI to MIDI converter) because I
> dont want to carry MIDI keyboard everywhere while testing
> trigger interactivity... so I test interactivity with keyboard input.
>
> Long story short - Qwerty KEYBOARD triggering (via KEY obj) of
> clips results in jittery playback... if I replace the KEY
> objects with NOTEIN objects... playback is smooth!!!
>
> I guess KEY object screws with scheduler or something...
> much more so than NOTEIN object.
>
> Yes, yes, yes, I am aware of VADE's recent posts to minimize
> jittery playback... tips like QMETRO, UNIQUE, etc...
> all awesome tips indeed - I use'um :>
>
> This most simple patch uses METRO2 and does not use UNIQUE
> (unique = message or atttribue (I forget) of Jit.movie.
>
> I will test this further but my point is that triggering clips
> via qwerty-keyboard input may be yet another culprit in
> Jittery playback...
>
> Anyone else know about this???
>
>


i mean using key object to trigger quicktime playback via

..assuming your metro2 object never stops.

I'm at work now but when I get home I will make most simple

test patch then upload for others to test... it was very late

when I came across this... I will test on MAC and PC

I just started to laff then went to bed :<

yes - 
i mean using key object to trigger quicktime playback via
jit.movie...
..assuming your metro2 object never stops.

I'm at work now but when I get home I will make most simple
test patch then upload for others to test... it was very late
when I came across this...  I will test on MAC and PC

I just started to laff then went to bed :<


Since I've heard conflicting information in the past on this subject, I'd like to be perfectly clear on this.

Is it correct that any lowly number box, even if hidden in some unopened sub-patch whose state has not been changed since the Babylonians, will still be updated by the Max scheduler and thus drain CPU?

I can understand how using [value] and/or [pattr] to display numbers via [prepend set] to a messages boxes would be less prone to GUI updates, but how does this help one with data that needs to be changed by the user as in the previous post? Does dropping an [autopatter @autoname 1] into that same sub-patch cause its state to only be updated when it changes?

BTW, I have noticed significant reduction in frame rates using signal level meters, multi-sliders, pwindows, and all the usual suspects. My solution is to use a 'GUI switch' which is a gate (and gate~) for all of the above so that you can use the GUI's to view all those things you would like to in your patch, but if the frame rates drop too low, you can cut them off and watch the frame rates soar. This is why I'm skeptical that number boxes whose states are not changing will eat up CPU, but I'm no expert.

I can understand how using [value] and/or [pattr] to display numbers via [prepend set] to a messages boxes would be less prone to GUI updates, but how does this help one with data that needs to be changed by the user as in the previous post? Does dropping an [autopatter @autoname 1] into that same sub-patch cause its state to only be updated when it changes? 

your problem is metro 2 and no @unique 1.

Metro does not drop frames at low priority like qmetro.

This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY 

fast. 60fps is metro 16(ish). Most likely your screen does not redraw 

I too am very skeptical, cause I use key in my max patch in multiple 

places to no detriment that I can measure.

On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:

> i mean using key object to trigger quicktime playback via

> ..assuming your metro2 object never stops.

> I'm at work now but when I get home I will make most simple

> test patch then upload for others to test... it was very late

> when I came across this... I will test on MAC and PC

> I just started to laff then went to bed :<

This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY  
fast. 60fps is metro 16(ish). Most likely your screen does not redraw  
faster than 60 hz vertically.

I too am very skeptical, cause I use key in my max patch in multiple  
places to no detriment that I can measure.

>
> yes -
> i mean using key object to trigger quicktime playback via
> jit.movie...
> ..assuming your metro2 object never stops.
>
> I'm at work now but when I get home I will make most simple
> test patch then upload for others to test... it was very late
> when I came across this...  I will test on MAC and PC
>
> I just started to laff then went to bed :<
>


this thread is full of voodoo, voodo and caps-lock

> your problem is metro 2 and no @unique 1.

> Metro does not drop frames at low priority like qmetro.

> This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY

> fast. 60fps is metro 16(ish). Most likely your screen does not redraw

> I too am very skeptical, cause I use key in my max patch in multiple

> places to no detriment that I can measure.

> On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:

> > i mean using key object to trigger quicktime playback via

> > ..assuming your metro2 object never stops.

> > I'm at work now but when I get home I will make most simple

> > test patch then upload for others to test... it was very late

> > when I came across this... I will test on MAC and PC

> > I just started to laff then went to bed :<

> your problem is metro 2 and no @unique 1.
>
> Metro does not drop frames at low priority like qmetro.
>
> This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
> fast. 60fps is metro 16(ish). Most likely your screen does not redraw
> faster than 60 hz vertically.
>
> I suggest unique 1
> Qmetro 16
>
> I too am very skeptical, cause I use key in my max patch in multiple
> places to no detriment that I can measure.
>
> On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:
>
> >
> > yes -
> > i mean using key object to trigger quicktime playback via
> > jit.movie...
> > ..assuming your metro2 object never stops.
> >
> > I'm at work now but when I get home I will make most simple
> > test patch then upload for others to test... it was very late
> > when I came across this...  I will test on MAC and PC
> >
> > I just started to laff then went to bed :<
> >
>
>

you keep saying voodoo, and I keep asking why, and get no response. :P 

On Jan 17, 2008, at 10:29 PM, yair reshef wrote:

> this thread is full of voodoo, voodo and caps-lock

you keep saying voodoo, and I keep asking why, and get no response. :P  
punk!

> this thread is full of voodoo, voodo and caps-lock
>
> On Jan 18, 2008 4:36 AM, vade  wrote:
> your problem is metro 2 and no @unique 1.
>
> Metro does not drop frames at low priority like qmetro.
>
> This will output matrices AS FAST AS POSSIBLE. Metro 2 is EXCEEDINGLY
> fast. 60fps is metro 16(ish). Most likely your screen does not redraw
> faster than 60 hz vertically.
>
> I suggest unique 1
> Qmetro 16
>
> I too am very skeptical, cause I use key in my max patch in multiple
> places to no detriment that I can measure.
>
> On Jan 17, 2008, at 3:38 PM, robert vanrhyn wrote:
>
> >
> > yes -
> > i mean using key object to trigger quicktime playback via
> > jit.movie...
> > ..assuming your metro2 object never stops.
> >
> > I'm at work now but when I get home I will make most simple
> > test patch then upload for others to test... it was very late
> > when I came across this...  I will test on MAC and PC
> >
> > I just started to laff then went to bed :<
> >
>
>


The thing is, if the number box is constantly being sent updates, then 

it will be part of the scheduler, and max will take time to re-draw it.

If a numberbox is not a UI element meant for interaction, remove/ 

replace it, or use [qlim] and limit the amount of updates per second 

On Jan 17, 2008, at 5:27 PM, Christopher Keyes wrote:

> Is it correct that any lowly number box, even if hidden in some 

> unopened sub-patch whose state has not been changed since the 

> Babylonians, will still be updated by the Max scheduler and thus 