Thanks @Bri_G! I wish I could take all the credit but it’s basically just a port of the Love2D implementation above. To give myself credit where it’s due, it wasn’t an easy port, but all the same it wasn’t code original to me.
…oh yeah I did also map it to the globe, so that’s something 
update: I forgot, this isn’t the version mapped to a globe, ignore that 
@sim @piinthesky - had a quick check on the parameter.boolean project in the examples. Saw the effect you mentioned - sometimes when you set or reset the switch occurs but is rapidly reversed.
Do you think that it is down to a narrow switch width and the touch covers both capture areas - so depending on where you touch, and how you remove your finger, the reversal occurs or not.
This one is showing the problem for me, thank you! We’ll track it down
I don’t think this is related to the new UI, but may be related to some of the render engine changes
Oh I forgot to mention in the release notes. This beta has a new “Set Project Icon” view. When you tap the Share button while your project is running you can “Set Project Icon”, which allows you to pinch and zoom your screenshot, or import files from elsewhere
I can no longer submit details on crashes. I get an error message and it won’t let me submit.
Thanks for helping me track this down, @piinthesky @UberGoober
The next build will have a fix for the boolean toggle issue. It was due to dispatching the Lua update from the UI thread while the frame was in-progress, which would read the value back out of the Lua state and then when the scheduled update ran, it set the boolean value to the wrong value
This was exacerbated by lower frame rates, so I didn’t notice it when I tested projects that ran reasonably fast
@sim great, boolean works now.
@sim - just reported a couple of crashes which I think were due to out of memory issues when printing variable values to the output window. My screen froze and after scrolling up to close Codea it crashed.
After adding output.clear() the issue was solved but the > symbol for opening the parameter window started flashing from dull to bright etc etc.
I’m getting used to a new iPad and expect the processing to be faster - is this expected or is it a feature of the latest beta ?
The new tab in fullscreen mode flashes whenever a print() happens, this is to let you know something is printing in the console. If you print every single frame then it will flash constantly. I will definitely look into the memory issues! I think we might need to limit the total amount of printing allowed
@sim - ahhh, that’s neat letting you know printing is occurring. On reflection it would probably be better to use parameter.watch for most monitoring if possible.
The print() statement is better if you are looking for a trend.
Thought - perhaps you could incorporate a counter in the the print statement or define a check variable say print.max() or print.count() then coupled with output.clear() you could limit your output to the printing. Another possibility - re-route your ouptput print results to an external file - are there any limitations on file size for apps that iOS imposes ?
Edit:
Just ran a basic test for project icon and it worked, thanks - but when I closed the project the icon was not in place but did appear when re-running the project.
Also, I have enclosed the test and when you run it the parameter window opens. I mentioned this before about default for parameter windows but this made me think the project is running as a one off short term project retaining the screen but not constantly looping through the code - is that the case.
function setup()
--
sW, sH, cW, cH = WIDTH, HEIGHT, WIDTH//2, HEIGHT//2
rectMode(CENTER)
stroke(255, 0, 22)
strokeWidth(8)
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
background(40, 40, 50)
fill(103, 233, 80)
rect(cW, cH, 600, 600)
fill(251, 255, 0)
rect(cW, cH, 300, 300)
end
@sim - couple of crashes in latest beta. I was trying to print out a couple of variable values I had placed two print statements in the touched() function and it resulted in two values I didn’t recognise.
When I tapped on one of those printed values Codea crashed. Repeated the test again and it took two or three taps before Codea crashed.
Just checking now on a third test, crashed again after tapping anywhere on output window several times in quick succession.
Could this be due to introducing the button strip at the bottom of the window and it requiring trap capture now on that window?
Edit: are we still recording beta testing errors in the spreadsheet set up by @Jon ?
Interesting, do you have the code that was crashing?
@sim the code where I checked this is quite involved so I just tried this, rapid tapping on the parameter window and this crashed.
-- TestCrash
function setup()
--
end
function draw()
-- This sets a dark background color
background(40, 40, 50)
strokeWidth(5)
end
@sim bottom left buttons do not seem to work anymore.
edit: i tell a lie…if you slide over the screen to get back to the code but then change your mind and slide back to running screen, then the bottom left buttons do not respond.
Well, that’s a great find. Thank you! Looking into a fix
Edit: fixed for next build. It required the most crazy hack to workaround what appears to be an iOS bug with interactive transitions that get dismissed prior to completion 
In case it comes in handy for anyone, here’s a dumb little kludge I use sometimes to avoid crashes from print() statements:
if math.random(1,100) == 100 then
print(whatever)
end
…that’s for when I have something I want to debug that happens every frame, but it’s okay if I don’t get every single frame’s worth of data.
@UberGoober - hmmmm, that’s an interesting approach. I take it it ignores however many random numbers generated that are not 100 until the random number does reach 100 - then it prints the value. Which is OK to reduce the number of times the print statement occurs but, if you are looking at a series of consecutive outputs to get a trend you could miss most of them.
But, you could use a counter and count out say 100 instances before completing the loop. I’ll have to try that.
Thanks
We’ll have to set a maximum size print buffer, thanks for finding a workaround in the mean time
Three demos with OVERLAY still present
Ellipse Modes
Parameters
ImageIO
Couple of nice new demos in there. Thanks
I think the gravity demo informational text needs to say something like “tilt your device to see gravity sensor at work” or something that instructs the user to tilt their device to see what the demo does.