Highlights all the output message operators when banged.
The H operator shouldn't have an output port but a right-side-locked
port type, and has been modified.
An oversight in the implementation of J and Y meant that the chain would
grow each frame, if there were at least two segments and the first
segment was locked by something like H. Example:
H
YY
This is not what we want. I've added a guard in the J and Y
implementations that checks if the glyph above (or for Y, to the left)
is an earlier part of the chain, and if it is, to return. This has the
downside of making long chains potentially having to enter the J code
repeatedly, only to end up doing nothing.
The STUN() in J and Y might no longer be worth it. It was used to
prevent further operators in the chain from running, but since we have a
guard now, the writes while looping might end up costing more time.
We don't have any good benchmark files set up right now, so we'll have
to test it in the future.
J and Y and now be chained (like YYYYYY) to copy a glyph across the
'wire' they form.
This is a simple implementation of the feature. This changes both J and Y to
have loops in their definitions, instead of being single reads and
writes, which will make them heavier and have a adverse effect on
benchmarks. It also makes it harder to explain how orca's VM works,
since these operators are now non-trivial and can't be used as examples
of trivial operators. But we've decided it's worth it.
Inputs on the right side of the operator are not marked with PARAM
(which denotes a haste input). This fixes the display of the variable
operator so that the text on the right is displayed white and not cyan;
which matches Orca.
Faster than the bit twiddling, given the types of data and programs we
have now. Also means we can drop the distinction between 'safe' and
'unsafe' indexing when bounds checking is or is not required. Also now
gives consistent results with orca JS for 'strange' symbols like :, ;,
etc.
Old orca-c feature that is not present in orca JS. This was using up the
'!' glyph, which we'll need back for MIDI CC. It was also using up the
'/' input key in the TUI, and added a bunch of stuff to the code that
probably nobody was using.
Nicola Pisanti