what's the difference between loadbang and initbang? initbang seems to be specialised for abstractions, but why not use loadbang for abstractions too?
-
\[loadbang\] <-\> \[initbang\]
-
I think there is no difference between the two. I've never used [initbang] though..
-
there are a couple of differences.
firstly, when i used initbang in my patches, i had lots of reports of it not working for people (windows users, i think)
so, if you want everyone to be able to use your patch, initbang is hazardous.the next part relates to how it works. it's a while since i used the [initbang] object (because too many people complained it didn't work for them), so i hope i remember correctly:
if you dynamically create an abstraction in your patch, then [loadbang] will not be triggered upon the creation of the abstraction. but [initbang] will be triggered when dynamically created.
also, i THINK i remember reading that [initbang] will pass on its bang BEFORE any connections are made from the abstraction to the parent patch. (so, initbang sends its bang before [loadbang] does)
i hope i have that correct. i very well could be mistaken.
-
one practical application and example:
you could make a synthesizer voice abstraction and have all the default parameters of the synth loaded using [initbang].
then, you would be able to use that same abstraction as part of a song, and initialize that song's parameter values with [loadbang]. so, first the initbang defaults would be loaded, and then the parameters that need to be changed for the song would overwrite the defaults, because [laodbang] comes after [initbang]
-
ok, that sounds interesting. where did you get that information, that initbang bangs before loadbang? can't remember, to have read that in the help patch of init bang, but at the moment i'm not on pd.... this would be an interesting point.
what do you mean with "dynamicallay create an abstraction"?
when i have an abstraction with a loadbang in it, that should trigger a [$1] object as the abstractions first argument, then this will be triggered at creation time - even when it's created in a running patch. not? -
I think the difference is [initbang] is banged when loading is started, and [loadbang] is banged when loading is complete.
-
>>what do you mean with "dynamically create an abstraction"?<<
you can send messages to your patch to tell it to create objects. here's a quick example:
-
create a new patch.
-
create a subpatch called [pd rulez]
-
in the parent patch, create a message like this:
[;
pd-rulez obj 50 50 osc~(
then, click on that message box, and have a look in the subpatch. there should be an [osc~] object created 50 pixels from the top and 50 pixels from the left.
for more info, have a look in the pd-msg section of pd-extended help. (it's either in 'help' or 'manuals' or somewhere)
-
-
@hardoff said:
one practical application and example:
you could make a synthesizer voice abstraction and have all the default parameters of the synth loaded using [initbang].
then, you would be able to use that same abstraction as part of a song, and initialize that song's parameter values with [loadbang]. so, first the initbang defaults would be loaded, and then the parameters that need to be changed for the song would overwrite the defaults, because [laodbang] comes after [initbang]
You could use [loadbang] for this too, as they fire in patches from most-nested to least-nested after they are all reated. [initbang] is mainly useful for doing things before the abstraction is connected into the parent patch, for example dynamic numbers of inlets and outlets.
http://lists.puredata.info/pipermail/pd-dev/2006-08/007346.html
if you dynamically create an abstraction in your patch, then [loadbang] will not be triggered upon the creation of the abstraction.
True, but you can send a "loadbang" message to the containing subpatch to initialize the contained abstractions.
-
cool, thank you all! a lot of new information...
@ hardoff: sry, i didn't know, that it's possible to create objects and abstractions by sending messages. but good to know. pd is very wide-ranging application, sometimes i don't know, where to begin as a newbie... -
>>if you dynamically create an abstraction in your patch, then [loadbang] will not be triggered upon the creation of the abstraction.
True, but you can send a "loadbang" message to the containing subpatch to initialize the contained abstractions.<<
there is still a difference because the initbang is local. i had a modular system where i was dynamically creating drum/synth/effects modules. Often i'd create 2 or 3 versions of the same module, tweak their values, and then later decide i needed another copy of an existing module. sending a loadbang message to that abstraction also reinitialized the existing modules, undoign all my good tweaks.
In hindsight, i should have just just put a spigot after the [loadbang] and closed it off after any adjustments had been made to the abstraction. My workaround at the time was more messy.
-
Ah how did you do that workaround?
I keep getting all the abstractions receiving the same data! -
forget that, I solved it!