That’s much better, they line up like a switch statement
I had no idea you could drop the post-colon paren like that
You didn’t want to show me that first?? 
I wasn’t even looking at his code, assuming correctly that it was excellent and bug free! Every day is a school day, I didn’t know that either.
1 Like
LOL I somehow had split that
gfx_ext_retina = ext_noinit = 1;
line into the opposite sections they were supposed to be
Corrected now, 1st line in each section now
I changed the conditionals over to the shorter style
Much better
Trying out a different section comment style
It might use up too many lines though
I’m going to read through some iconic jsfx and see if something jumps out as better
TrackNotes_v2.jsfx (6.0 KB)
About that conditional style
I notice that tale mixed his conditional style in the same script
eg
VS
Yes, that’s perfectly congruent. He only uses the style that avoids cascading indentation where that matters in the big list of checks.
Using parens/braces in general avoids bugs. This looks nice:
idx < len ? (
strcpy_from(tmp = #, buf, idx);
strncpy(buf, buf, idx);
str_setchar(buf, idx, c);
strcat(buf, tmp);
) :
str_setchar(buf, idx, c);
len += 1;
But the indentation here could be misleading if somebody came along, perhaps from Pythonville, trying to add something to the ‘else’ part:
idx < len ? (
strcpy_from(tmp = #, buf, idx);
strncpy(buf, buf, idx);
str_setchar(buf, idx, c);
strcat(buf, tmp);
) :
str_setchar(buf, idx, c);
str_setchar(buf, 0, 'O');
len += 1;
That 2nd str_setchar is in the else block at all, it’s actually in the len += 1 scope/block!
So although there’s only a single statement in the else you highlight, changing to the funkier style is a potential foot gun. There’s actually an option in clang-format to force using braces around braceless one liner blocks because of this risk.
Looking good. Now I think some konstants would be good:
gfx_ext_retina = 1;
kBlack = 0; kWhite = 1; kGrey = 2; // etc
fontcolor = kWhite ? (
gfx_set(1, 1, 1);
) :
fontcolor == kBlack ? (
gfx_set(0, 0, 0);
)
I know you’d need to rearrange the slider content since the fg/bg colour numbers are different for the same colour, but getting rid of magic numbers also removes the need for the comments in the right column.
In the comment up above that block, the only bit of information we can’t get from looking at the code is that it’s from slider1, which is a good bit of info.
I’m busting your balls at this stage though. It’s not important. There’s just a move to banish comments like this:
// add a to b
b += a;
… from existence. Your names are great and descriptive so we can read the code and comments should compliment that, not duplicate the hard work you’ve already done.
Also there’s a thing where comments that duplicate what’s in the code can eventually become wrong when the code gets updated and the comments stay the same.
Btw I won’t get annoyed or anything if you blank whatever I’m saying for now and charge on, I’m just trying to get across some of the details of clean code that should read well. Something I am trying to get better at myself.
There are arguments against what I’ve said too. In JSFX there aren’t any actual constants so we are creating more variables, so in an @sample block it might be better doing things differently for performance.
JSFX could do with having constants and a @compiletime section that 100% comes before everything else that can be used for setup.
That’s pretty much why I hadn’t touched that yet
I put white font and black background first,
just in case someone else used it and chose the first options on both,
black font and black background, and got a blank screen
Is kBlack/kWhite just a convention?
Because otherwise I could use fBlack for the fonts, and bBlack for the background,
so the font and background order in the menus can be whatever I want it to be.
(which isn’t carved in stone yet)
eg
fWhite = 0; fGrey = 1; ...
bBlack = 0; bGrey = 1; ...Otherwise, it’s prob small enough code not for the numbers to be a problem?
Edit:
or possibly kBlackFont, kBlackBG would do the trick?
Seems pretty clear, and I can ditch the comments
Yeah, it’s no biggie at all. You can just give the script a different name not to be limited by previous versions and you can select default values in the bit where the sliders are defined to choose a sensible combo. There’s nothing stopping users from changing to white/white, green/green so it’s not worth worrying about beyond how easy it is to get back from that.
But you can call those variables anything you like, the k prefix is just a standard prefix for kconstant things, but you can use capitals or ignore all conventions if you like. They aren’t constants anyhoo so it’s just a hint that they shouldn’t be changed and always have the same value.
Those ones at the end are fine!
edit: I should say that having an eye on extending functionality is good. So forgetting about the old version at this early alpha stage is okay and going for just kWhite or whatever, since you might want to add highlighting etc next that use colours too.
So you reckon define them all after the gfx_ext_retina line?
Or at the start of each group?
I was thinking the start of each group so it’s obvious, they’re right there
Already doing that
I’d put them only in @init, I just checked and couldn’t get @gfx not to respect a normal colour variable in @init. They should be available in @slider from there too.
I wouldn’t put them at the beginning of each section, there are always going to be some things (functions, variables) used in different sections but they should only be declared once if possible for code duplication reasons.
Sweet! I still do think it’s a bit unusual preserving the different order of the same colour selection in the sliders when we can set different default values for them via the first number.
Useful and cool project, up until now I’d been putting all notes in empty items on tracks which still might be handy but it’s very useful to have comprehensive track notes on the control panel.
I’ll use it a lot for mix info i.e variations and general alteration info, cheers
1 Like
Woot, a user!
Remember Morgon to bypass the plugin for ZERO CPU usage
It still displays the same, tcp or mcp
You only need to turn it ‘on’ to edit the text
Still early days for the colours here
If you have a certain colour theme you prefer, just drop us the hex number(s)
Adding cut and paste would be a biggee, but not sure if we can hack that as I read the OS isn’t accessible
Cut paste is doable, it just wouldn’t use the system clipboard so it would just be within the plugin or between instances. With a partner Lua script you could definitely do it with the system clipboard as well.
I wrote an MPC emulating thing a couple of years back that used it’s own JSFX plugins in combination with a master Lua script. Even if vanilla Lua couldn’t access the system clipboard I did a another experiment a couple of years back where you can just add what you need via a bit of C++ magic:
Highlighting is interesting when you are not working with monospaced fonts since there’s a lot of string measuring involved to see what character the mouse is at. Unless it’s all key command based, which could be a faster way to get it started.
Both of those are great news, fill me in when convenient.
I’m learning Lua too so doubly interesting
I just read that thread you linked to Snooks, impressive
Its tragic to read ‘banned’ under your name though
What about hitting Ollie up to reinstate you? Judders managed to weasle back in somehow. Kenny was prob the wrong guy to ask.
Try linking to that thread and say how you’d like to continue your work contributing to Reaper
Nah, I like helping you and brainwreck here. Not a fan of strictly business corporate forums.
Very much appreciated too. I’m also not a fan of people being blocked from talking about people things.