Old 04-16-2012, 05:47 AM   #81
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Justin, another JS suggestion for when you're done revamping the entire language: it would be really useful if Jesusonic plugins could send and receive OSC messages in the same way OSC control surfaces can now. Some of the much requested stuff that we now 'have to' do outside of REAPER could then also be done inside REAPER, such as parameter feedback to MIDI controllers, or a virtual CV system like for VCA mixer groups).
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-16-2012, 06:56 AM   #82
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

Quote:
Originally Posted by dub3000 View Post
tried again with the brand-new latest DLL, results appear to be pretty much the same as the previous one (32-bit).
Confirmed here too (32-bit, not tested x64 yet): as far as I can tell arrays are not faster than in 4.22, it depends on what you do.. It could even be a bit slower. It looks promising in the perf window but not with a real monitoring tool. Globally I can see a tiny overall imrprovement but much erratic use of the CPU:



^^cheap dual core, win xp. Same zoomed image attached. Very only diff between the 2 graphs: the new jsfx.dll. The erratic thing seems to happen when there are array accesses from everywhere (@sample, @gfx, @block).
Anyway, in both cases, I'm not sure such a vu-meter pumping 14-16% of the cpu on its own could be released For the record, the optimized version w/o array but 64 vars instead (!) uses 5% CPU with full load, i.e. 64 channels. I'll test a stack solution when I have a minute.
Quote:
Originally Posted by cyco130 View Post
Here's a small but useful js function, just to show that this new addition opens up some very cool possibilities that may not be immediately recognizable:
Code:
@init
    function malloc(size)
        local(result)
    (
        result = heapTop;
        heapTop += ceil(size);
        result;
    );

    // Allocate 200 ms delay buffers for each channel
    delayBufferL = malloc(srate * 0.200);
    delayBufferR = malloc(srate * 0.200);

    // Report memory usage
    freembuf(heapTop);
Automatic memory management for JS
I'd call this func AddSomething() but not malloc haha! I'm not sure you posted that folowing the sucky suggestion I did about allocations (?) but if so my suggestion was not really to have alloc/realloc features but -if it makes sense- to "delegate" such things to us. So, for ex, no bounds checking on REAPER side but at the cost of bad JS's to crash REAPER, of course.
Attached Images
File Type: jpg CPU_mix_big.jpg (30.0 KB, 240 views)
File Type: jpg CPU_mix.jpg (41.6 KB, 953 views)

Last edited by Jeffos; 04-16-2012 at 07:04 AM.
Jeffos is offline   Reply With Quote
Old 04-16-2012, 07:16 AM   #83
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by Justin View Post
I've just updated the builds, with that optimization fix (- being + for constants).
Fixed, thanks.

Quote:
Originally Posted by Justin View Post
The builds are now compiled with ICC (as they would be in a REAPER release), so that might affect performance (positively!) too.
I just ran two tests on my work machine (an ancient Core2 Duo E6300 1.86GHz running WinXP Pro x86), a very dumb delay that actually moves 441 samples each @sample call using an array, and a tone generator adding up 220 sines each @sample call (no arrays here):

Code:
                 v4.23pre1a   jsfx_functions
Delay            47.7%        27.1%
Tone generator   34.8%        33.2%
So the performance improvement is there, although without arrays I guess it is less profound.

EDIT: I just ran the same two tests on a Core2 Duo E6550 2.33GHz running REAPER x64 on Win7 Pro x64:

Code:
                 v4.23pre1a   jsfx_functions
Delay            38.7%        22.1%
Tone generator   27.8%        26.5%

Last edited by Tale; 04-16-2012 at 07:57 AM. Reason: Added x64 results
Tale is offline   Reply With Quote
Old 04-16-2012, 07:43 AM   #84
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

humm.. wow 20% better !? where do those % come from Tale? from REAPER's perf meter window? could you post the JS?
just in case: here's attached the test project + JS I used for the graphs above (sucky effect, just for test: lots of array accesses)
Attached Files
File Type: zip test_CPU.zip (5.2 KB, 171 views)
Jeffos is offline   Reply With Quote
Old 04-16-2012, 08:06 AM   #85
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by Jeffos View Post
humm.. wow 20% better !? where do those % come from Tale? from REAPER's perf meter window?
I am talking about the CPU usage as REAPER reports it in the status bar of the FX window.

Quote:
Originally Posted by Jeffos View Post
could you post the JS?
Sure.
Attached Files
File Type: txt delay.txt (170 Bytes, 171 views)
File Type: txt tone_generator.txt (279 Bytes, 177 views)
Tale is offline   Reply With Quote
Old 04-16-2012, 08:12 AM   #86
IXix
Human being with feelings
 
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,889
Default

Quote:
Originally Posted by Justin View Post
maybe we can come up with some hybrid of the two that can have it all. I'll think about this some more...
Justin Frankel can't resist a challenge .

Quote:
Originally Posted by Justin View Post
Having said that, I am curious about thoughts where the namespace system reaches its limits -- not in general, but for this application. It already allows for a huge amount of reusability, perhaps that will be enough...
I've got no idea where the limit is but I'm looking forward to finding it. It would be nice to be able to pass objects around instead of treating blocks of memory as objects but I ain't complaining. I suspect that all this new stuff is going to make manipulating those blocks of memory much easier anyway.
IXix is offline   Reply With Quote
Old 04-16-2012, 08:40 AM   #87
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

@Tale: thanks! yes, confirmed much better results with your test JS "delay" indeed (I see 15% better here, I use perfmon.exe)
#é!?#&ù!? Ok, so this might depend on what/where you code + "the age of the captain" as we say in French
Jeffos is offline   Reply With Quote
Old 04-16-2012, 08:50 AM   #88
IXix
Human being with feelings
 
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,889
Default

There's a bug lurking in the debug list code. I thought that adding/subtracting constants was still broken but it turned out that the list just wasn't showing the right values when I saved/recompiled. Seems to be working properly now. Should've got a screen shot .
IXix is offline   Reply With Quote
Old 04-16-2012, 10:03 AM   #89
cyco130
Human being with feelings
 
Join Date: Apr 2012
Posts: 4
Default

I've spotted a bug where calling an undeclared function with dots (like when you misspell the function name: myObject.myFunxtion) crashes Reaper. Unfortunately it happens very sporadically, I couldn't isolate a simple case. I'll report more about it if I can reproduce it reliably.

Also, I didn't check if it was already the case in the release version but % operator seems to have higher precedence than array access operator []. So a = b % c[3] is parsed as a = (b%c)[3]. This caused me a good amount of time trying to understand what was going wrong

Quote:
Originally Posted by Jeffos View Post
I'd call this func AddSomething() but not malloc haha!
Haha, it's nothing like malloc of course. But it does work beatifully for (semi)static arrays

Quote:
Originally Posted by IXix View Post
There's a bug lurking in the debug list code. I thought that adding/subtracting constants was still broken but it turned out that the list just wasn't showing the right values when I saved/recompiled. Seems to be working properly now. Should've got a screen shot .
I can confirm that. But it doesn't happen all the time.

Quote:
Originally Posted by Justin View Post
Having said that, I am curious about thoughts where the namespace system reaches its limits -- not in general, but for this application. It already allows for a huge amount of reusability, perhaps that will be enough...
I'm playing around with a proof-of-concept GUI library, based on passing around memory pointers but manipulating them with namespaces. Goes well for now, except the occasional need for event callbacks for more generality, which I don't expect any time soon But loosening the 3 arguments limit could have lead to an easier-to-use design.
cyco130 is offline   Reply With Quote
Old 04-16-2012, 10:29 AM   #90
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by cyco130 View Post
I've spotted a bug where calling an undeclared function with dots (like when you misspell the function name: myObject.myFunxtion) crashes Reaper. Unfortunately it happens very sporadically, I couldn't isolate a simple case. I'll report more about it if I can reproduce it reliably.
I will look into this and try to duplicate too.
Quote:
Also, I didn't check if it was already the case in the release version but % operator seems to have higher precedence than array access operator []. So a = b % c[3] is parsed as a = (b%c)[3]. This caused me a good amount of time trying to understand what was going wrong
It is, and it's also the case with ^, and a few other operators. Ack! I'm going to fix, but hoping that fixing it doesn't break a lot of existing JS that depend on that (incorrect) behavior.
Justin is offline   Reply With Quote
Old 04-16-2012, 01:21 PM   #91
beyond
Human being with feelings
 
Join Date: Jun 2007
Location: Palm Beach FL
Posts: 265
Default

Firstly, thank you Justin and the other brilliant people behind Reaper!

Here are some of my ideas...

Code:
function F(#Code#)
(
  #Code#;
);
This will open the possibility for macros, lambda functions, passing object references, and much more syntactic candy!

I vote for hidden *.inc extension for includes, as that will encourage clean bundling by the directory of the author, while /../ in path names can reference external shared libraries.

If we can get some basic string and output functions, JS can become a rather serious musical programming language, programmable in the context of loaded songs and production! Also, file change detection of loaded JS programs, so when you save it in an external editor and it re-compiles automatically, would be a very significant time saver...

Long live Reaper!
beyond is offline   Reply With Quote
Old 04-16-2012, 01:32 PM   #92
bang
Human being with feelings
 
bang's Avatar
 
Join Date: Jul 2006
Posts: 626
Default

Quote:
Originally Posted by Banned View Post
[...]it would be really useful if Jesusonic plugins could send and receive OSC messages[...]
++1! would love to add OSC support to arp!0.
bang is offline   Reply With Quote
Old 04-16-2012, 01:49 PM   #93
bang
Human being with feelings
 
bang's Avatar
 
Join Date: Jul 2006
Posts: 626
Default

Quote:
Originally Posted by Justin View Post
It is, and it's also the case with ^, and a few other operators.
including !foo[] == (!foo)[] i hope.
Quote:
Originally Posted by Justin View Post
Ack! I'm going to fix, but hoping that fixing it doesn't break a lot of existing JS that depend on that (incorrect) behavior.
i've spent more than a little time finding bugs from this odd precedence and will be grateful for a fix.

and since we seem to be in Jesusonic dreamtime, the one feature that would have saved me gobs of time debugging is some sort of basic variable declaration:

dim theVariable;
tehVariable= 1; //error please!

fwiw, /dan
bang is offline   Reply With Quote
Old 04-16-2012, 02:05 PM   #94
vocalid
Human being with feelings
 
vocalid's Avatar
 
Join Date: Sep 2009
Location: Middle of nowhere (where the cheese comes from)
Posts: 483
Default

Quote:
Originally Posted by bang View Post
...basic variable declaration:

dim theVariable;
tehVariable= 1; //error please!

fwiw, /dan
please please pretty please?
vocalid is offline   Reply With Quote
Old 04-16-2012, 02:55 PM   #95
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Just noticed, looking at code, but havent tested -- accessing regXX may crash heh.

I'm actually looking at modernizing the front end of eel to match the new back end. Fun with yacc!
Justin is offline   Reply With Quote
Old 04-16-2012, 03:15 PM   #96
beyond
Human being with feelings
 
Join Date: Jun 2007
Location: Palm Beach FL
Posts: 265
Default

Quote:
Originally Posted by Justin View Post
I'm actually looking at modernizing the front end of eel to match the new back end. Fun with yacc!
EEL for Reaper? Too cool for words!

http://eel.olofson.net/features.html

"EEL code can generate and compile EEL code at run time", ah the power of metaprogramming...
beyond is offline   Reply With Quote
Old 04-16-2012, 03:17 PM   #97
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by Justin View Post
[...] I'm actually looking at modernizing the front end of eel to match the new back end. [...]
That sounds pretty gross.

__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-16-2012, 04:17 PM   #98
Tranquil
Human being with feelings
 
Join Date: Feb 2005
Location: Greece
Posts: 100
Default

Quote:
Originally Posted by beyond View Post
EEL for Reaper? Too cool for words!

http://eel.olofson.net/features.html

"EEL code can generate and compile EEL code at run time", ah the power of metaprogramming...
that EEL has nothing to do with REAPER's EEL.
although both live in the water
Tranquil is offline   Reply With Quote
Old 04-16-2012, 09:33 PM   #99
Kundalinguist
Human being with feelings
 
Kundalinguist's Avatar
 
Join Date: Nov 2008
Location: Toronto, Canada
Posts: 4,630
Default

I feel like I'm watching a foreign film festival, caught up in the excitement but not understanding a single thing. I missed that day at school when they were teaching JS coding.

Hope there will be some green functions, too, like compost and recycle.

R.
__________________
Success is just one more plugin away! And happiness is as close as your next upgrade. (On the interweb: www.rolandk.ca / www.auroraskypublishing.com)
Kundalinguist is offline   Reply With Quote
Old 04-17-2012, 08:01 PM   #100
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

OK, updated again on April 17. Changes in this version:
  • Some small fixes, optimizations
  • Changed the way expressions such as a ^ mem[x], a ~ mem[x], and a % mem[x] are parsed. It used to be (erroneously) (a^mem)[x], but it is now a^(mem[x]), which makes a lot more sense. Hopefully this doesn't break existing plug-ins! It really could!
  • In fixing this, I noticed there are a lot of other areas where the logic does not match what one would expect. For example: x % 2^y is parsed as (x%2)^y. We can't go changing all of these rules, so I'd suggest that everybody use () religiously, and especially whenever you use %, ~, or ^.
  • I spent a bunch of time writing new flex/bison rules trying to emulate JS/EEL. I have it 90% of the way there, but there are a lot of constructs that JS/EEL code often uses that are a real pain to properly support. At some point we should probably make an EELv3 that ditches compatibility, but that's a ways off. Some of the perks of the new code (which isn't finished but is at least limping) are nice, though, such as more descriptive errors with accurate line numbers, support for EEL functions with more than 3 parameters, etc. Someday, I guess, we'll make JS2.

Some things I'm going to do soon:
  • optional support for explicit variable declarations
  • include/import support for functions (probably with .inc files in the same path as the js, and make REAPER ignore *.inc when scanning).
  • look at having more of win32's jsfx.dll compiled with ICC, it looks like it never really was (though the win64 version is). Anybody have any performance summaries with the most recent builds?
  • Edit (added thoughts): I'm going to make a script that will check the existing library of JS effects to see if they are affected by the most recent precedence change. I will also experiment with fixing other precedence issues, provided of course the affected plug-ins are minimal enough, heh.

Last edited by Justin; 04-17-2012 at 08:30 PM.
Justin is offline   Reply With Quote
Old 04-17-2012, 08:42 PM   #101
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by Justin View Post
[...] We can't go changing all of these rules, so I'd suggest that everybody use () religiously [...]
Amen.
Quote:
Originally Posted by Justin View Post
Someday, I guess, we'll make JS2. [...]
ReaSurrection, Hallelujah!
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-17-2012, 09:48 PM   #102
bang
Human being with feelings
 
bang's Avatar
 
Join Date: Jul 2006
Posts: 626
Default

Quote:
Originally Posted by Justin View Post
Changed the way expressions such as a ^ mem[x], a ~ mem[x], and a % mem[x] are parsed. It used to be (erroneously) (a^mem)[x], but it is now a^(mem[x]), which makes a lot more sense. Hopefully this doesn't break existing plug-ins! It really could!
also ! mem[x] is now !(mem[x]). thanks.
Quote:
Originally Posted by Justin View Post
In fixing this, I noticed there are a lot of other areas where the logic does not match what one would expect. For example: x % 2^y is parsed as (x%2)^y. We can't go changing all of these rules, so I'd suggest that everybody use () religiously, and especially whenever you use %, ~, or ^.
when the dust settles, could we please a definitive operator precedence list? i for one really like to know *why* i'm using ().
Quote:
Originally Posted by Justin View Post
[...]soon: optional support for explicit variable declarationss are minimal enough, heh.[/list]
fantastic! tia!

and fyi, something seems wrong with JS: midi_logger with the latest update on osx 10.6.8 w/ Reaper 4.22pre2.

enjoy! /dan
bang is offline   Reply With Quote
Old 04-17-2012, 10:31 PM   #103
dub3000
Human being with feelings
 
dub3000's Avatar
 
Join Date: Mar 2008
Location: Sydney, Australia
Posts: 3,955
Default

We could trivially build some sort of basic JS smoke test by defining a project with one of each js plugin with random settings, rendering as float32, and doing a before/after diff on the output file across different js versions. Just have to leave out plugs that use random numbers.
dub3000 is online now   Reply With Quote
Old 04-18-2012, 01:52 AM   #104
IXix
Human being with feelings
 
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,889
Default

So much love!

Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
IXix is offline   Reply With Quote
Old 04-18-2012, 02:29 AM   #105
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

bug: stack_exch(x) replaces the top of the stack but it does not "exchanges" it
Jeffos is offline   Reply With Quote
Old 04-18-2012, 02:30 AM   #106
vocalid
Human being with feelings
 
vocalid's Avatar
 
Join Date: Sep 2009
Location: Middle of nowhere (where the cheese comes from)
Posts: 483
Default

Quote:
Originally Posted by IXix View Post
So much love!

Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
BLOATWARE!!!!

I agree with you IXix
vocalid is offline   Reply With Quote
Old 04-18-2012, 03:24 AM   #107
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by IXix View Post
Regarding changes to precedence, why not implement a method for new plugins to use the new precedence?
Code:
@init
js_version = 2;
Then any plugin that doesn't specify a version could just use the old precedence.
But then you'd have to start every new script you write with those same boring lines, which seems kinda lame to me. I would rather fix the few scripts (if any) that actually exploit the old precedence, and be done with it.
Tale is offline   Reply With Quote
Old 04-18-2012, 03:44 AM   #108
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

But there are hundreds of JSFX coming with Reaper... who's gonna check them all for that precedence inconsistency?


BTW, how about allowing the users to rename the JS effects from Reaper's FX browser, without messing with the actual filename? I'd really love to do this.

Also, how about displaying JS subfolders in the FX browser as actually subfolders in the tree...

And, how about adding an extension for JS scripts? Something like .jsfx (so it doesn't clash with JavaScripts)?


[img]http://img295.**************/img295/9007/fxbrowse.png[/img]


Wouldn't this be a lot nicer? Yes, ED, it would!

Last edited by EvilDragon; 04-18-2012 at 07:30 AM.
EvilDragon is offline   Reply With Quote
Old 04-18-2012, 04:29 AM   #109
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by EvilDragon View Post
But there are hundreds of JSFX coming with Reaper... who's gonna check them all for that precedence inconsistency?
Sure. But the same goes for any of the JS changes. Anyway...

Quote:
Originally Posted by Justin View Post
I'm going to make a script that will check the existing library of JS effects to see if they are affected by the most recent precedence change. I will also experiment with fixing other precedence issues, provided of course the affected plug-ins are minimal enough, heh.
So, apparently Justin is gonna check them all.
Tale is offline   Reply With Quote
Old 04-18-2012, 06:58 AM   #110
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

My script lives! The only thing it found in the stock JS was this, in midi_arp:
Code:
    pbvarpos > nvar || !notelist[pbnotepos] ?
Which I guess means that it fixes a bug in midi_arp, as I can't imagine that working right in the old JS!

I will try out some other changes and run them on all of the stock JS -- if anybody has scripts that they want me to test parser changes against, you can PM me them..
Justin is offline   Reply With Quote
Old 04-18-2012, 07:00 AM   #111
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Jeffos View Post
bug: stack_exch(x) replaces the top of the stack but it does not "exchanges" it
Hmm, what OS/arch? It is working here on win32 and win64...

Last edited by Justin; 04-18-2012 at 07:15 AM.
Justin is offline   Reply With Quote
Old 04-18-2012, 07:09 AM   #112
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

win32 too..

may be you can try this:
Code:
@init
stack_push(3);
stack_push(2);
stack_push(1);
stack_push(7);
stack_exch(2);
DEBUG0=stack_peek(0); // should be 2
DEBUG1=stack_peek(1);
DEBUG2=stack_peek(2); // should be 7  but remains 2 (in the JS debugger at least)
DEBUG3=stack_peek(3);
EDIT:
Quote:
Originally Posted by Justin View Post
Anybody have any performance summaries with the most recent builds?
oh and I still see CPU "spikes" with *some* JS effects (eg the one I attached http://forum.cockos.com/showpost.php...5&postcount=84) whilst the same JSs are "smooth on the CPU" in v4.22

Last edited by Jeffos; 04-18-2012 at 07:18 AM.
Jeffos is offline   Reply With Quote
Old 04-18-2012, 07:18 AM   #113
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Jeffos View Post
win32 too..

may be you can try this:
Code:
@init
stack_push(3);
stack_push(2);
stack_push(1);
stack_push(7);
stack_exch(2);
DEBUG0=stack_peek(0); // should be 2
DEBUG1=stack_peek(1);
DEBUG2=stack_peek(2); // should be 7  but remains 2 (in the JS debugger at least)
DEBUG3=stack_peek(3);
Ooops, this wasn't clear -- stack_exch(x) exchanges the value of x onto the top of the stack... it's essentially tmp=stack_pop(); stack_push(x); x=tmp; (but faster).
Justin is offline   Reply With Quote
Old 04-18-2012, 07:20 AM   #114
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

ha ha! Ok, thanks (that's an English bug on my end then )
Jeffos is offline   Reply With Quote
Old 04-18-2012, 07:24 AM   #115
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by Justin View Post
My script lives!
Yay!

Quote:
Originally Posted by Justin View Post
The only thing it found in the stock JS was this, in midi_arp:
Code:
    pbvarpos > nvar || !notelist[pbnotepos] ?
Which I guess means that it fixes a bug in midi_arp, as I can't imagine that working right in the old JS!
Well, probably not in this case, but if notelist == 0, then I guess !notelist[pbnotepos] could be shorthand for notelist[pbnotepos+1]... But that is not very likely, now is it?
Tale is offline   Reply With Quote
Old 04-18-2012, 07:25 AM   #116
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Jeffos View Post

oh and I still see CPU "spikes" with *some* JS effects (eg the one I attached http://forum.cockos.com/showpost.php...5&postcount=84) whilst the same JSs are "smooth on the CPU" in v4.22
Hmm, that project is working fine -- CPU on that meter is 6% instead of 9% (in 4.22), and it doesn't really seem to spike much here. If you view the process CPU use in task manager, they are pretty similar looking, though maybe a touch lower with the new build.
Justin is offline   Reply With Quote
Old 04-18-2012, 07:27 AM   #117
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by Justin View Post
Ooops, this wasn't clear -- stack_exch(x) exchanges the value of x onto the top of the stack... it's essentially tmp=stack_pop(); stack_push(x); x=tmp; (but faster).
I usually don't care about names, but... I don't suppose stack_exch could be renamed to stack_xchg (like the x86 instruction)?
Tale is offline   Reply With Quote
Old 04-18-2012, 07:38 AM   #118
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Woot! Changing it so that x (%|~|<<|>>) y ^ z is parsed as x OP (y^z) instead of (x OP y) ^ z. x^y^z will still be (x^y)^z, and I've tested it against all of the JS I have and it didn't break anything. I'll post a build later today...
Justin is offline   Reply With Quote
Old 04-18-2012, 08:38 AM   #119
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Tale View Post
I usually don't care about names, but... I don't suppose stack_exch could be renamed to stack_xchg (like the x86 instruction)?
Haha, err, I guess we should probably just stick to what it is already?

Also I should note, you can use stack_peek(x) to both read or write the stack at arbitrary offsets, i.e:

Code:
x = stack_peek(2);
stack_peek(2) = y;
If you pass a constant to stack_peek(), it optimizes more, and it is faster.
Justin is offline   Reply With Quote
Old 04-18-2012, 09:12 AM   #120
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Builds updated, now with the !/%/~/<</>> precedence vs ^ fixes.
Justin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:30 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.