Cycling 74 » Topic: (feature request) Loadbang delay argument http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/feed Wed, 19 Jun 2013 22:56:59 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-50659 <![CDATA[(feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-50659 Mon, 31 May 2010 20:01:09 +0000 Hugobox Hi!
I keep finding myself using lots of loadbangs with various delays and it would be nice if the loadbang object could take an integer as an argument that would be a delay time in miliseconds.

What do you think?

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181725 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181725 Mon, 31 May 2010 20:22:03 +0000 Chris Muir In a complex giant patcher, the initialization gets quite complex. The method I settled on, in the largest patch that I use, is to start a metro/counter at the top left corner of the top level patch that counts to 100 at a rate of 5ms / tick. I send this value around via a [send load_percent] and elsewhere in the patch I compare load_percent to some threshold, and initialize when load_percent has crossed that threshold. This allows me a deterministic order of initialization across a giant patch, albeit at the cost of a half second longer load time.

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181726 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181726 Mon, 31 May 2010 21:39:46 +0000 Roman Thilenius i use an abstraction which allows 9 arguments for 9 different delay times.

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181727 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181727 Mon, 31 May 2010 21:57:18 +0000 Hugobox Thanks for the ideas!

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181728 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181728 Mon, 31 May 2010 22:46:37 +0000 Christopher Dobrian I don’t understand why having the delay built into loadbang would be any better than using a delay object. (That’s what it’s made to do: delay a bang.)

A different approach would be to use a single loadbang at the top level and use send or forward to send the messages you want where you want in the order you want. What with all the objects such as b, t, delay, pipe, uzi, etc., you can construct about any sort of ordering system you want. Here’s a ludicrous example.

– Pasted Max Patch, click to expand. –
]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181729 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181729 Mon, 31 May 2010 23:22:37 +0000 Luke Hall I wrote a javascript implementation of an ordered [loadbang] which you can find in the linked blog post. If you skip back to the previous post there is a bit more of an explanation. Otherwise I often tend to use one master [loadbang] and use an approach similar to the method Chris suggested. I hope it helps.

lh

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181730 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181730 Tue, 01 Jun 2010 06:20:00 +0000 EMV I wrote a little abstraction to do delayed loadbangs.
The first (optional) argument specifies a delay time in ms. (Optional)arguments after the first one will be sent out as a message after the delay (so it’s loadbang and loadmess with a delay function).

Stick it in a patcher, save it as ‘loadbangdelay’ (that’s how I named it anyway) and put it in the Max path.

– Pasted Max Patch, click to expand. –
]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181731 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181731 Tue, 01 Jun 2010 07:31:36 +0000 jvkr Be prepared to discover that this scheme (delaying loadbangs) not always works flawlessly. What I found to work better is that a process which has finished (eg loading a file, filling a buffer) triggers the next step in the sequence. And I use deferlow abundantly. The scheduler’s ways are unfathomable (sometimes).

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181732 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181732 Tue, 01 Jun 2010 09:18:25 +0000 broc For me Initialization order is the most tricky and mysterious part of Max.
In particular, I wonder how to handle self-initializing live.* objects in combination with loadbang initializations of other objects.

Any comments on this?

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181733 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181733 Tue, 01 Jun 2010 11:16:16 +0000 pid @broc, total agreement (as you know!).

i used to think i had a pretty good handle on max initialisation, but since m4l and live.* objects came along, the thing is a minefield. every time i do anything i build test patches which give me different results to the last initialisation-test-patches i made.

so, +1 to broc, any comments always good…

(p.s. – gives me great heart to read the great jvkr’s comment “The scheduler’s ways are unfathomable (sometimes)”)…

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181734 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181734 Tue, 01 Jun 2010 16:36:11 +0000 Hans Höglund I think the delay approach is problematic. Generally you should make a clear distinction between startup time and run time which is scheduled time in Max. If you definately want to defer something to the scheduler at startup defer is a better choice.

In complex patchers it is good to only use one loadbang object, connected to a trigger and possibly send/receive so that you can initialize sub-modules of your patch in a deterministic way. This would correspond to writing multiple init functions in a programming language, and call them all from the main function.

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181735 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181735 Tue, 01 Jun 2010 22:50:29 +0000 broc @Hans – your approach makes perfect sense to me. Thanks for explaining.

So I think the confusion comes only with MaxForLive where Max behaves different in some aspects. But that’s another story..

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181736 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181736 Tue, 01 Jun 2010 22:54:31 +0000 Chris Muir Hans: The order of send/receive itself is non-deterministic, isn’t it?

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181737 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181737 Wed, 02 Jun 2010 00:08:30 +0000 Roman Thilenius  
it is getting interesting here now.

jvkr is right:
delayed loadbangs sometimes do not work as exspected, for example
when drawing to lcd or loading files from disk, and mostly when the delay is too short.
so be careful what you do, never forget that maxmp is a young girl.

answer to christopher:
for the same reason why you make abstractions in any other situation.
110.loaddels 400 500 600 700 800 900 1000 is simply less writing compared to
loadbang del 400 del 500 del 600 del 700 del 800 del 900 del 1000 and
connect them.
 
(the same is true for ordered loadbangs – see my abstraction attached.)

 
then a little idea about how to organize/find the required load order.

1.
you are the programmer, you must simply decide and take responsibilty yourself.

2.
what can really help to do so, is that you do not put any loadbangs in your
subpatches (except inside abstarctions, where it is unavoidable), but have
a “loadbang-input” to you bigger subpatches and/or bpatchers, in order to
keep overview and/or control the load order.

3.
important for beginners: do not use delays only because you are unsure how
to organize order. learn how to organize order!
 
 
 attached files:

110.loadargs
110.loadinstance
110.loadlater
110.loadprint
110.loadrebang
110.loadsolo
110.loadunisym
 
have fun 

-110
 

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181738 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181738 Wed, 02 Jun 2010 00:42:25 +0000 Hans Höglund The order in which objects of the same name receive messages is (basically) not deterministic, however using a trigger to invoke separately named objects is. The name would correspond to the submodule being initialized, of course.

I use the word “basically”, since the first case would actually depend on creation order which is of course subtle.

The following patcher should make this all clear.

– Pasted Max Patch, click to expand. –

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181739 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181739 Wed, 02 Jun 2010 10:52:38 +0000 broc The documentation clearly states:
“The order of reception by two or more receive objects is not deterministic.”

So it’s quite simple: if you need deterministic behavior, avoid multiple receivers
(which is easy by giving them different names).

]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181740 <![CDATA[Re: (feature request) Loadbang delay argument]]> http://cycling74.com/forums/topic/feature-request-loadbang-delay-argument/#post-181740 Wed, 02 Jun 2010 11:52:20 +0000 Hans Höglund Well it is not uncommon for a behaviour to be deterministic under the hood even if it is not documented/specified. Such behaviour may of course change without warning and should not be relied on.

As I originally stated: use one loadbang, different receivers ;)

]]>