"initialization" v "On Activate"


#1

hello group GP mind…what is the difference between the “initialization” and “On Activate” callbacks?

thanks,

tony


#2

Initialization is only called once
Is meaningful for init some variables to initial values

On Activate is called whenever you switch to the rackspace


#3

right, i got that part, but what do they do that is different? how do i know when to use one or the other?

what does it mean “is called only once”? once per rackspace script? once per gig file? but you can have many “On Activation” calls in a script?

thanks…so many questions…i’m not even sure what the questions are until i get some initial answers!


#4

GP Scripts are specific to rackspaces. Each rackspace’s GP Script can have one Initialization callback.
That Initialization callback is called just once when the rackspace is first loaded. If you have 5 rackspaces each containing a script, each script’s initialization callback will be called.

Note - the order in which the Initialization callbacks are called is indeterminate

The On Activate callback is called whenever you switch to a rackspace.

These things are all explained in the language manual

That’s completely up to you


#5

the language manual is great, i’ve been using it liberally…but it’s all explained if you understand the basics of this stuff! i didn’t even know what a “callback” was until beginning to work with GP Script. and many other things as well. i really need to learn more about scripting, etc…i know it says early on that the guide materials assume some basic knowledge of scripting etc., so maybe i should get that somewhere. anyway, i continue to thank you all for your patience and generosity. i’m very excited about what i am able to do by adding scripting to the “basic” GP functionality, which is amazing already.


#6

Yeah, a programming language is a mixed blessing. If one knows basic programming concepts, then GP Script is pretty easy. Unfortunately if programming is not one’s background then it’s much harder. Our original vision for GP Script was for a mechanism to experiment with ideas that would ultimately end up getting implemented directly in Gig Performer. For example, it’s clear that some built-in ramp automation will be very valuable.

We really don’t want our users to expect to have to be technical. We want them to be able to stay focused on musical creativity.


#7

i think it’s fine to have a deeper level of knowledge needed for something like scripting. what would be most useful to someone like me would be to have some resources for background - if there’s any kind of basic text for this stuff (i know the GP Script language is its own thing), and/or a glossary, and/or suggestions on what i need to know/where to go to get into it. not that you guys need more on your plater…as it is, i am getting somewhere despite virtually no experience (and with a lot of help from pianopaul, yourself, and some others), so it’s not too bad.