JS programming questions

[dsilver]

Hi- New user of Jesusonic with REAPER here. I LOVE it.

I have a C programming background so I feel quite comfortable with Jesusonic rules, but I'm having a few problems.

1- I can't seem to get sliderchange() to work. The display doesn't seem to get updated until I click on the slider.

2- The reference says that set_slider() takes an effect number as an argument, i.e. 1.3 would be effect 1, slider3. What is the definition of an effect number? Where do I get it?

3- Any way to get debugging info out, other than using slider displays?

4- The docs state that the code x=5; will define a variable called x and set it to 5. It further states that buffer=1024; will set buffer to point to the 1024th location in temporary storage. Is "buffer" a reserved variable name? It isn't on the list of "special variables."

5- Any possibility of user defined functions? Or #includes or #defines, just for readability?

That's good for a start. Thanks for any help.

David

[LOSER]

Originally Posted by dsilver

1- I can't seem to get sliderchange() to work. The display doesn't seem to get updated until I click on the slider.

Use 'sliderchange(2^(slidernumber-1));' this will update the slider with the slidernumber as index. As they are bitmasked (i.e. lowerst bit first slider next bit 2nd slider ... you may add those 2^(slidernumber-1) values, e.g. sliderchange(2^0+2^3); this will update slider1 and slider4).

Originally Posted by dsilver

2- The reference says that set_slider() takes an effect number as an argument, i.e. 1.3 would be effect 1, slider3. What is the definition of an effect number? Where do I get it?

The postion in the FX chain == effect number AFAIKT.

Originally Posted by dsilver

3- Any way to get debugging info out, other than using slider displays?

Try 'Crtl+K' (on a variable) in the editor to lookup a variable. But thats about it...

Originally Posted by dsilver

4- The docs state that the code x=5; will define a variable called x and set it to 5. It further states that buffer=1024; will set buffer to point to the 1024th location in temporary storage. Is "buffer" a reserved variable name? It isn't on the list of "special variables."

No, but it specifies the offset. Since JS only uses one memory buffer (array) the variable before the array crackets also defines its offset, too (like the variables in the brackets).

Originally Posted by dsilver

5- Any possibility of user defined functions? Or #includes or #defines, just for readability?

No.

[Justin]

you can also do sliderchange(slider1) and it'll notice that you passed it slider1, and update it accordingly...
or you can use the bitmask (2^(idx-1))

-Justin

[IXix]

I'm confused about the memory buffer thing too!

Originally Posted by the manual

x = 5; // set x to equal 5

buffer = 1024; // set buffer to reference the local memory starting at 1024

To my eyes, there's no difference between those two statements, so how does JS know that 'buffer' should start at 1024? Why doesn't x reference the local memory starting at offset 5? Is it down to where in the code the statement appears or something? What am I missing?

[LOSER]

Originally Posted by IXix

To my eyes, there's no difference between those two statements, so how does JS know that 'buffer' should start at 1024? Why doesn't x reference the local memory starting at offset 5? Is it down to where in the code the statement appears or something? What am I missing?

You are refering to this, right?

   buffer = 1024; // set buffer to reference the local memory starting at 1024
   x=buffer[0]; // read first item in buffer
   buffer[1]=x; // write to second item in buffer
   buffer[n]=x; // write to n'th item in buffer

I.e. you need to take a look at the WHOLE example

You could also have foo[n] where 'foo'+'n' is the offset in the local memory (contrary to e.g. C/C++ where only 'n' would define the offset and 'foo' the element/array...)

[IXix]

I was still confused but in the process of formulating my reply, I think I've understood how it works.

'buffer' itself doesn't point to the memory location, it's just a variable with the value 1024. Writing buffer[n] is the same as writing 1024[n], which will retrieve the 1024th item in the memory, yes?

[LOSER]

Originally Posted by IXix

I was still confused but in the process of formulating my reply, I think I've understood how it works.

'buffer' itself doesn't point to the memory location, it's just a variable with the value 1024. Writing buffer[n] is the same as writing 1024[n], which will retrieve the 1024th item in the memory, yes?

Yes and some more words for the sake of it ...

EDIT: It will, however, retrieve the '1024+n'th item [/nitpicker]

[dsilver]

I am the original poster of this question and at first the explanations given still didn't make sense to me, but upon further reflection I realized that it is all very simple and I couldn't understand it at first cause I was overcomplicating it.

What I believe to be the case is this:

There is no difference between the statements

buffer = 1024;
and
x = 5;

in that each one creates a local variable and initializes it.

It is the act of putting square brackets after one of these variables that turns the variable into a pointer, i.e. makes it operate by reference.

So, buffer[0] references the value stored at the 1024th location in local memory. And buffer[1], buffer[2] reference subsequent values. But there is nothing special about the variable "buffer".

So when the docs say:
buffer = 1024; // set buffer to reference the local memory starting at 1024

I think this is misleading. "buffer" isn't being set to reference memory starting at 1024 any more than every other statement which creates and initializes a variable, such as "x = 5;" sets that variable to "reference memory starting at location whatever (in this case 5)."

The fact is that any variable can be used as a pointer into local memory if [] is put after it. So if "buffer" happens to be set the VALUE 1024, then buffer[0] is essentially the same as 1024[0].

All in all it's very handy and very simple. But I think the docs should make clear that there is no special voodoo going on in the buffering example. It is also important to realize that the space which is allocated for the variables themselves, i.e. "buffer", "x", etc. is allocated elsewhere. So one is free to use any location one wants to use within local memory.

So, looking at each of the following lines individually,

1000[1] = 6;
1[1000] = 6;
x = 500; x[501] = 6;
y = 501; y[500] = 6;
buffer = 1001; buffer[0] = 6;
buffer = 1000; buffer[1] = 6;
buffer = 0; buffer[1001] = 6;

All of them do the EXACT same thing with regard to memory location 1001.

"x" and "y" and "buffer" are just variables which can be used in any way variables can be used.

Sorry if this seems all too obvious, but if I can help clear up confusion for someone I think it is worth it.

[dsilver]

and let me add that looking at the previous posts again, I realize that with my long treatise I just said pretty much the same thing IXix said in two sentences. Oh well, I guess brevity isn't my strong suit this time!

[IXix]

Originally Posted by dsilver

and let me add that looking at the previous posts again, I realize that with my long treatise I just said pretty much the same thing IXix said in two sentences. Oh well, I guess brevity isn't my strong suit this time!

LOL. It took me about twenty minutes to compose those two sentences.

At least this thread should help any poor C people like us to understand how it works. That line in the manual is very misleading indeed. If it wasn't for that I would have figured it out for myself.

Originally Posted by LOSER

EDIT: It will, however, retrieve the '1024+n'th item [/nitpicker]

True. For some reason I thought I'd put '0' rather than 'n'. My brain does funny things sometimes.

[Till]

thank you dsilver. i think now everybody (including me) got it. that documentation is in fact misleading...

[thcjunkee]

Originally Posted by dsilver

Oh well, I guess brevity isn't my strong suit this time!

I, for one, am happy you sacrificed brevity for the sake of clarity. And, speaking as a neubee, I am REALLY happy I found this thread! aloha... mark