@VirtualVirgin The editor drives me batty. It functions so differently to what I'm used to that I'm constantly making subtle typos that fail to compile.

I'm looking into coding in my familiar code editor and hopping back to HISE just to hit F5. Thinking about it, there might even be a way to automate it. Set up a file watcher and every time a script file int he HISE project is saved, tell HISE to compile. 🤔

@VirtualVirgin might work, try it in the compiled plugin and let us know

@d-healey Right on both counts of course!!

@VirtualVirgin hard to tell without knowing what scribeData is

@d-healey Actually, I think I just found the error:

local MPN = direction == "up" ? noteObject.y[0] : noteobject.y[noteObject.y.length -1];

vs.

local MPN = direction == "up" ? noteObject.y[0] : noteObject.y[noteObject.y.length -1];

I forgot the camelCase on noteObject for the false branch :P

@aaronventure Thanks!
This is great! What a useful feature.

@d-healey yeah something like JSON.delete(obj, key) is the easiest way, the delete syntax would require a real brain-twister with the current parser.

@d-healey They are now in the docs: https://docs.hise.audio/scripting/scripting-api/scriptpanel/index.html#setmousecursor

@d-healey said in Just wondering about how this logic condition evaluates:

@VirtualVirgin said in Just wondering about how this logic condition evaluates:

Yes! That is the solution :)

You can probably also get rid of the ternary operator at the end - ? true : false because the statement itself should return true or false.

Yes, that makes sense. It is just evaluating to that anyway, so no need to make it redundant.

@VirtualVirgin parseInt and trace

I think I made a video about undocumented functions (if I didn't I should).

I think the reason is just that the JS parser can‘t build namespaces across multiple files, but I don’t think there‘s a valid reason for touching that part of the codebase…

I just found this on the forum compliments to @HISEnberg ! 🙏

https://forum.hise.audio//post/100409

Content.makeFrontInterface(200, 50); const var Label1 = Content.getComponent("Label1"); const var lblCss = Content.createLocalLookAndFeel(); Label1.set("text", "CSS Label"); // Email/Key Label Laf lblCss.setInlineStyleSheet(" * { letter-spacing: 2px; font-weight: regular; } /** Render the default appearance. */ label { background-color: var(--bgColour); color: var(--textColour); border-radius: 5px; padding-left: 50px; padding-right: 20px; text-shadow: 2px 2px 5px rgba(0,0,0,0.3); } /** If you edit the text, it will use this selector. */ input { text-align: left; padding-top: 0.5px; padding-left: 50px; padding-right: 20px; caret-color: white; font-weight: bold; } /** Style the text selection with this selector. */ ::selection { background: #50FFFFFF; color: white; } "); Label1.setLocalLookAndFeel(lblCss);

@d-healey There isn't a particular standardization spec for MIDI 1.0 timestamps that I am aware of so I was thinking the HISE timestamp would be related to an internal clock. I would expect the output to be in samples, milliseconds or maybe PPQ, but I don't see that reflected in your Console.print there.

@Christoph-Hart
How do the timestamps for MIDI messages work in HISE?

@Chazrox Thanks!!

@d-healey Good to know! I LAF everything so I didnt notice this was even broken.

@d-healey It's those kinds of catches that make you a legend, mate.

@VirtualVirgin The doc you see in the API browser is auto generated from the HISE source.

Link Preview Image HISE/hi_scripting/scripting/api/ScriptingApi.h at 372a9e682cff2f3b52ee432ae50977fc95d9173c · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_scripting/scripting/api/ScriptingApi.h at 372a9e682cff2f3b52ee432ae50977fc95d9173c · christophhart/HISE

favicon

GitHub (github.com)

There are a couple of ways to edit the docs depending on if they are auto-generated or not.

If you see bafcb1ce-22ff-4c1a-8fe6-cf7f08bca43b-image.png then you can click that to edit the doc directly.

For the rest of the docs you should clone the docs repo, make your modifications, and make a pull request.

Bit of info here too - https://docs.hise.dev/working-with-hise/project-management/documentation/contributing.html#setup

@VirtualVirgin yeah once in on init is good

@VirtualVirgin

You shouldn't declare a function within a paint routine or mouse callback. I'm pretty sure that will reallocate memory for every redraw of the screen or mouse movement.

Functions should be declared in on init, and 99% of the time they should be inline functions.

For paint routines and the like for your factory functions, I would declare them outside of the factory function - unless they're really short. This is more of a code cleanliness thing though than a performance issue.

local t = Engine.createTimerObject(); t.setTimerCallback(function[panel, t, rangeMinMaxArray]

Why don't you use the panel's built in timer instead of using a separate timer object?