Closed furiousgreencloud closed 2 years ago
this bug, is appears for K operator too.
This is the Oscean wiki repository o_o
In any case, it looks like the expected behavior, described here.
What did you expect would happen?
i know, but source hut does not have bug reports, where is the correct place for these? i searched around and his was the only mention of bug reports.
I would expect that as before V&K operators should go anywhere.
i had written .orcas that use this feature/bug, which now don't work, so this is confusing. sorry i didn't check the detailed documentation, thought it was part of the optimization. I'm also getting other errors, yet to isolate....
The use case is that the only way to use the full screen, as very few operators move north.
I like .orcas that are entirely visible, so that people can see the process in a live coding context, this demystifies the "score". So I'll use a V to get back to the top of a new column of processing.
Top left of three05.orca
Orca is not like a cellular automata, it runs each cell in a sequence from the top left, to the bottom right. Reading up is a bit of an anti-pattern in orca, so variables are normally set at the top, but you can bring data upflow with the O
and Q
operators, like in the screenshot.
You also hit other bugs?
We can keep using this thread, I don't mind, normally I use the lines forum for that, or the mailing list.
Any idea, why upward V used to work. Sounds like top to right, is an established pattern.
Yeah, I forgot to clear the variable buffer at the end of the frame, that means that opening a new file, or forgetting to wipe variables would use whatever was left in memory in the last variable write.
Other bugs – where stack underflows, and divide by 0, could because i changed with display/grid dimensions, for my non 16:9 display.
#
# New bigger Orca-Toy Canvas is Great but a little tooo wide on my display,
# Feel Orca should have and old school maybe 1.33':1 (VGA) or 1.37:1 (35mm) aspect ratio
#
# The H->J key change is just because H is hide on macos.
#
would this diff be safe:
diff --git a/src/main.tal b/src/main.tal
index 1af9b2c..1e67482 100644
--- a/src/main.tal
+++ b/src/main.tal
@@ -87,7 +87,7 @@
AUTO-YADDR
( size )
- #0320 .Screen/width DEO2
+ #02ca .Screen/width DEO2
#01c0 .Screen/height DEO2
( synths )
@@ -300,7 +300,7 @@ BRK
( select-all/insert )
[ LIT 'a ] !~ ,&no-a JCN ;set-selection-all JSR2 &no-a
[ LIT 'i ] !~ ,&no-i JCN ;toggle-insert JSR2 &no-i
- [ LIT 'h ] !~ ,&no-h JCN ;toggle-guide JSR2 &no-h
+ [ LIT 'j ] !~ ,&no-h JCN ;toggle-guide JSR2 &no-h
( tempo )
[ LIT ', ] !~ ,&no-slow JCN #ff ;mod-speed JSR2 &no-slow
[ LIT '. ] !~ ,&no-fast JCN #01 ;mod-speed &no-fast
Instead, I added a button in the interface :)
https://user-images.githubusercontent.com/1455726/153281931-05efb6c3-b3e1-4c20-aea4-0130826a959b.mp4
nice!
how about the
- #0320 .Screen/width DEO2
+ #02ca .Screen/width DEO2
is that the only place the width is defined. Will changing it have any side effects?
Oh! you're right, updated the new default width.
Changing this is safe, but uxn only has 64kb of memory, your grid cannot be larger than (64kb - the size of the orca rom)/4
, otherwise the grid data will start overwriting the program.
I'd love to see what gives you Division by zero and stack underflow, was it that you made really large grids?
i was only making the screen narrower, so that should have used less memory.
V operator seems to only read correctly from a 'source'/writter that is on a lower line number, that the source +1.
For example this .orca:
places clear boxes, at the ? positions and not under all Va's 5 each frame as expected.
Bug Demo .orca
bad-V.orca.txt
Version Info:
orca-toy (via git log -n 1)
uxn:
os: