when in an abstraction i want to use a value as argument, i use a
message box [#1], and to have this value output (when opening the
patch) I use a loadbang.

but if i change the argument once the patch is opened (and in edit
mode) how to have the sub-patch in abstraction “see” the new value??
(other than banging from the top level)

thanks

kasper

#P outlet 390 123 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 390 100 21 196617 $1;
#P newex 390 74 48 196617 loadbang;
#P connect 1 0 2 0;
#P connect 0 0 1 0;
#P window clipboard copycount 3;
–
Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

typing a new argument into an objectbox reloads the abstraction
and therefore reloadbangs the [# i] inside.

hm?

-110

yes, actually… which means i have another problem…..

if i save the enclosed patch as an abstraction ( I called it loadtest
but could be anything) when i load it, or when i change the argument,
the “print” inside of it reports the change….. meaning you are
right.

but a “print” at the outlet of the abstraction does not “see” anything….

I am really puzzled there…..

thanks

kasper
–
Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

humm, if i forget to paste the patch i guess i will stay puzzled even longer..

here it is

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 95 186 82 196617 print atloadtime;
#P message 49 114 34 196617 1000;
#P newex 49 93 32 196617 sel 0;
#P newex 49 42 48 196617 loadbang;
#P number 106 81 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 71 147 46 196617 / 1000.;
#P message 49 72 47 196617 $1;
#P inlet 106 61 15 0;
#P outlet 71 208 15 0;
#P connect 5 0 2 0;
#P connect 2 0 6 0;
#P connect 6 0 7 0;
#P connect 6 1 3 0;
#P fasten 4 0 3 0 111 132 76 132;
#P fasten 7 0 3 0 54 132 76 132;
#P connect 3 0 0 0;
#P connect 3 0 8 0;
#P connect 1 0 4 0;
#P window clipboard copycount 9;

–=–=——=–=——=–=——=–=——=–=——=–=—-
#P window setfont “MS Sans Serif” 10.;
#P window linecount 1;
#P newex 64 71 48 8585226 deferlow;
#P newex 130 244 82 8585226 print atloadtime;
#P message 49 157 32 8585226 1000;
#P newex 64 122 30 8585226 sel 0;
#P newex 64 47 52 8585226 loadbang;
#P number 106 124 35 10 1 0 1 131 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 106 205 46 8585226 / 1000.;
#P message 64 101 21 8585226 $1;
#P inlet 106 104 15 0;
#P outlet 106 266 15 0;
#P connect 3 0 0 0;
#P connect 3 0 8 0;
#P connect 1 0 4 0;
#P connect 7 0 3 0;
#P connect 4 0 3 0;
#P connect 6 1 3 0;
#P connect 6 0 7 0;
#P connect 2 0 6 0;
#P connect 9 0 2 0;
#P connect 5 0 9 0;
#P window clipboard copycount 10;

Jihadly yours,

Dr_Sbaitso

this seems to be reproducable on the magic 110 computer.

a [pipe 0] helps – or a delay 0 behind the loadbang.

i am used to do this from bpatchers (in conjuntion with
plug-in initialisation) but i am surprised i
never noticed it with abstractions before.

now lets find an explanation for this … hm.

ah yes, maybe … i think the outer print _does_not_
know_that_it_is_connected_ to the abstraction, when you
click in the main patch to release the object box
of the subpatch, the loadbang comes first, then the
outlets are connected to the upper level.

-110

konfuzius 110

a deferlow instead of pipe will save you some grey hairs. As far as I
know the pipe problems haven’t been resolved yet, and it would work with
any kind of message, not only numbers and for sure is a million times
more CPU saving…

> now lets find an explanation for this … hm.
>
> ah yes, maybe … i think the outer print _does_not_
> know_that_it_is_connected_ to the abstraction, when you
> click in the main patch to release the object box
> of the subpatch, the loadbang comes first, then the
> outlets are connected to the upper level.

There was a thread about the order of execution of loadbangs, and as far
as I remember its an isuue on the to-do lists of cycling…

It also explains why deferlow works…

Stefan

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

No, Konfusionzius…

Stefan

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

stefan, what has this french food done to you!

when we type a new argument into a messagebox
we do not need to watch out for “CPU saving”
unless it is a french patch.

i am sorry about all those problems on OS X but
on my OS 9 machine the [delay] object does _not
have any problems. :)

Pete

#P window setfont “Lucida Grande” 10.;
#P window linecount 1;
#P newex 15 50 48 10 deferlow;
#P newex 81 218 96 10 print atloadtime;
#P message 0 131 32 10 1000;
#P newex 15 96 30 10 sel 0;
#P newex 15 24 71 10 loadmess $1;
#P number 57 98 35 10 1 0 1 0 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 57 179 46 10 / 1000.;
#P inlet 57 78 15 0;
#P outlet 57 240 15 0;
#P connect 8 0 5 0;
#P connect 4 0 8 0;
#P connect 5 0 6 0;
#P connect 5 1 2 0;
#P connect 3 0 2 0;
#P connect 6 0 2 0;
#P connect 1 0 3 0;
#P connect 2 0 7 0;
#P connect 2 0 0 0;
#P window clipboard copycount 9;

On 9/18/06, Roman Thilenius wrote:
>
>
>
> > James Aldridge wrote:
> > > knofunctuous?
> >
> > No, Konfusionzius…
> >
> > Stefan
>
>
>
> stefan, what has this french food done to you!
>
> when we type a new argument into a messagebox
> we do not need to watch out for “CPU saving”
> unless it is a french patch.
>
> i am sorry about all those problems on OS X but
> on my OS 9 machine the [delay] object does _not
> have any problems. :)
>
>
>
>
>
> –
> “Volume is Always Green, Pan is Always the Same Knob.”
>

It’s a doozie!! ;)

If you share patches with people who are still using pre-OS X
hardware, loadmess is going to be one of those things that you will
want to avoid or write an abstraction to emulate.

On 19-Sep-2006, at 0:28, Peter Reid wrote:

> I’d like to take this opportunity to mention the [loadmess] object
> for those that don’t know it. (writing [loadmess #1] would save
> the use of one message box!!!)

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

I’m sympathetic to those using old versions of the software, and if I
were doing a particular project for such a person, I would certainly
keep those limitations in mind (I’m sure Peter has an annotated list
of new features and objects to be avoided for each point release
since Max 3.5, updated quarterly). But to generally recommend that
people avoid all new, dare I say >>useful< < features that have arisen
in the past 5 years of Max development when doing general day-to-day
patching is, IMHO, silly.

Of course, Peter knew I would take the bait and has a wry reply
waiting…

jb

Am 19.09.2006 um 09:46 schrieb Peter Castine:

> loadmess is cute, but don’t forget that it was first introduced in
> 4.5.5 or so.
>
> If you share patches with people who are still using pre-OS X
> hardware, loadmess is going to be one of those things that you will
> want to avoid or write an abstraction to emulate.

Peter is quite the wryly wryer I must say. If I wake up on the right side of the bed, some of his replies can be pretty funny so long as I haven’t had my coffee yet!

James

The OSX system is so much more stable than OS9, and Max has also
improved a lot over the last three years, not only in terms of new
features added, but also stability. So unless one can’t afford a newer
computer (which is fair) I have problems understanding why anyone would
want to stick with OS9. And I will be very surprised if anyone manage to
convince me otherwise.

Best,
Trond

Jeremy Bernstein wrote:
> Er, bleah. If one refrains from using all post-Max 4.1 features, out
> of concern for those still using OS9 versions of Max, that rules out
> an amazing mess of stuff. But hey, if you want to reproduce
> pattrstorage using Max 4.0 objects, go crazy.
>
> I’m sympathetic to those using old versions of the software, and if I
> were doing a particular project for such a person, I would certainly
> keep those limitations in mind (I’m sure Peter has an annotated list
> of new features and objects to be avoided for each point release since
> Max 3.5, updated quarterly). But to generally recommend that people
> avoid all new, dare I say >>useful< < features that have arisen in the
> past 5 years of Max development when doing general day-to-day patching
> is, IMHO, silly.
>
> Of course, Peter knew I would take the bait and has a wry reply
> waiting…
>
> jb
>
> Am 19.09.2006 um 09:46 schrieb Peter Castine:
>
>> loadmess is cute, but don’t forget that it was first introduced in
>> 4.5.5 or so.
>>
>> If you share patches with people who are still using pre-OS X
>> hardware, loadmess is going to be one of those things that you will
>> want to avoid or write an abstraction to emulate.
>
>

and for the record, loadmess have been introduced in 4.5 :-)

Cheers,
ej

> Why on earth would anyone these days want to keep running Max under
> OS9?

I use on stage an old powerbook 145b to display informations for
musicians (connected thru MIDI to another computer). It’s an easy,
_totally_ silent, stable, and cheap solution. And the Os is even
system7. I build standalones for this laptop with my good old Max3
running on an old Mac clone under OS8.6.

And as we don’t have much money, we still use our old Mac8500s, under
OS8.6. If we need small machines for installations running during
monthes, they are just perfect.

My copy of CW runs under OS8.6 and I was still using it to do externals
for Max4.5 (with Max4.6, I have to use XCode!) not so long ago. I had
no reason to pay for an upgrade.

There are also people around me who didn’t want to spend more money for
Max and stopped buying updates (some of them use Max only a few hours a
moonth, for small projects). If I have to do patches for them, then I
have to avoid new objects, event if they are very handy.

But when I work under OS Max4.5, then of course I’m very happy to use
the newest objects.

To answer your question, people still use Max under OS9 because of
money! And I still drive a small old car for the very same reason.

p

…(I’m sure Peter has an annotated list
> of new features and objects to be avoided for each point release
> since Max 3.5, updated quarterly) …

…

> jb
>
>
Seriously- is there a list like this anywhere?!

Also,
is it possible to get old versions of Max still? I have a few old boxes I’d
love to resurrect.

sorry to go so OT

Pete

For better or worse I rely on my memory.

You’re all gonna miss me when I’m dead and gone.-

> But to generally recommend that people avoid all new, dare I say
> >>useful< < features that have arisen in the past 5 years of Max
> development when doing general day-to-day patching is, IMHO, silly.

Nothing wry or witty today, sorry.

Nor would I recommend that people avoid useful features. Rather, I
feel it’s worth *balancing* utility and backwards compatibility. And
on this front, while loadmess is nice, I wouldn’t rate it super-high
in utility level. Compared to loadbang -> messagebox it saves a grand
total one object and one patch cord. That’s not the same utility gain
as, say pfft~ (remember patching fourfold overlapping Hanning windows
with fft~/ifft~ ?).

How high backwards compatibility weighs in the equation is something
people have to answer for themselves. For people who only ever write
patches for themselves and one Max installation, it’s not an issue.
The more your work is distributed over different machines and
different clients, the more it is an issue.

On 19-Sep-2006, at 10:37, James Aldridge wrote:
> Hear ye, hear ye! If need be, the Os9erZ can create a loadmess
> abstraction with ease!

With ease, eh? Including anything from 1 to 255 arguments?

We’re waiting. (But, no, I’m not holding my breath.)

On 19-Sep-2006, at 10:41, Trond Lossius wrote:
> Why on earth would anyone these days want to keep running Max under
> OS9?

Wrong modal verb, Trond. I daresay (almost) everybody here *wants* to
have a few 17″ 2.16GHz MacBook Pros to work with.

Are you offering to buy one, plus the next Max/MSP upgrade, plus OS
10.5 (whenever it comes) for everyone on the list?

There are innumerable reasons why people *need* to run older hardware
and software. Money is merely the most obvious reason, but it’s
hardly the only one. And in many cases the people programming Max are
not the people who make the decisions about what hardware their
patches will be run on, as I’m sure you’re aware.

> OSX system is so much more stable

Red flag time.

In general, yes, OS X is more stable. But I’ve had System 8.6 (not to
mention System 6.0.7) machines that *in a specific configuration*
were every bit as stable for particular tasks. Our backup server
hasn’t seen a crash for years (a claim I cannot make about any OS X
machine here) and it’s running System 8.6. Alas, AppleShare on OS
10.4 won’t play nice with older AShare implementations, so I need to
find a new backup solution.-(

At least my Lombard never spontaneously combusted. Have you seen the
videos of those burning SONY batteries?

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

French food? I have to cook myself, french food is either only available
for the upper 100 class or overpriced and bad (at least here in Paris).
Fortunately I like to cook, its like making music…

> i am sorry about all those problems on OS X but
> on my OS 9 machine the [delay] object does _not
> have any problems. :)

I was reffering to pipe, not delay.

If even Joshua acknowledges a problem… ( http://tinyurl.com/s8ezj )

The advantage of deferlow over delay: it accepts any message.
The advantage of deferlow over pipe: it does not need the overhead to
remember possibly 1000 events (only numbers, no messages) and you only
want to delay a single event…
If you need several scheduler ticks to get something working (if you set
pipe or delay to a value bigger than 0). Then its better to rethink the
logic of the patch.
Though I must admit some objects still miss a bang when loaded. vst~ for
example (some plugs are really big…), that could force you to delay
(but never to pipe)…

pipe is fine for the original purpose, but bad for repairing things…

And for really stable music making machines I can recommend an Atari
with CLab software. (not to forget M and Jam which ran on those machines
as well… ;-)

Stefan

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

In general I am very much into using gear as long as possible, and as
long the old machine runs…

But I would hesitate to get into old gear again. And I just use the
newest stuff for whatever I pull out now…

For paid efforts, its always cheaper to by a new machine than to adapt
existing goodies to an old machine…

And if update prices are a concern, then its better to switch to Pd.
Linux will run well on pretty old x86 hardware too, but you can always
run the newest Pd on it.

Stefan

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

right, [pipe] needs like a giaghertz or so and that
probably makes it unusable for initialisation of live
performance patches. ;)

> The advantage of deferlow over delay: it accepts any message.

the avantage of [delay] is that it is available for OS 9.

> remember possibly 1000 events (only numbers, no messages) and

normally there is only one loadbang in an abstraction, but i can
see how speed would matter with 1000.
(it is always good to learn new things about [pipe] but at the
moment my main idea of this thread is [argueing with stefan~] )

> Though I must admit some objects still miss a bang when loaded. vst~ for
> example (some plugs are really big…)

thats only a matter of order.
unfortunately “plug-in has been finished loading” isnt part of
the VST specs … we could need that well for [vst~].

>> pipe is fine for the original purpose, but bad for repairing things…

i am good in braking things.

-110