Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hmm, not sure whether i fully understand this (and mind that i don't
have a full overview of how RjDj works in my head).first of all, you have to define, what you mean by "fully loaded". a somewhat naive definition might be: "when the source of the patch has
been loaded and everything in the patch has been properly initialized". (the tricky part is of course the "properly initialized") consider a patch that loads soundfiles into an array, and does so by using: [loadbang]->[delay 5000]->[read myfile.wav myarray(->[soundfiler] now the patch will be properly initialized 5000 milliseconds after the
patch has been loaded. there is no way to properly detect this.a simpler example would involve no [delay] on the patch side (that is:
everything is initialized directly via [loadbang]). now [loadbang]s are executed depth first: if you have an abstraction
containing a [loadbang] and another abstraction also containing a
[loadbang], the "inner" [loadbang] will always fire before the "outer" one. to make it the other way round, use [loadbang]->[delay 0] in the inner
abstraction. (since timing is not crucial in your case, the above will most likely be
just accurate enough)
You did understand my problem very well! :)
The approach from above is what I'm currently playing with and for "well-behaved" patches that don't use [delay]s after loadbangs themselves, it works pretty okay.
another thing: if the patch/scene is loaded with something like [;pd open myscene.pd .(
the [loadbang]s in "myscene" will fire before the sending of the
open-message returns. something like:| [t b b] | [; pd open myscene.pd .( | [print loading-done]
Hm, that's a very interesting approach, maybe this can work in RjDj, depending on I how switching "scenes" is realized internally (which I don't know).
Frank