Following last week’s open beta, here’s a new revision with some additional bug fixes.
As noted by members of the community, it is recommended to make a backup of your projects before upgrading to this beta, as older firmware versions won’t be able to open project created with 1.14 beta versions.
How to join
This is an open beta. Just hop on to the beta website to get it!
The updated manual is available as well. (PDF version is unavailable for the moment).
How to send feedback
For all feedback, please send an email to beta@squarp.net
Please note we will not consider any feature request at this stage. Bug reports, small suggestions and general feedback is welcome. For all bugs, please provide a clear step by step procedure to reproduce it, so that we can fix it more easily.
Well, I’m having to downgrade firmware for the first time. I have encountered new bugs that have crippled my device usage more than any of the previous bugs. I have already submitted an email bug report, this is just so people can see.
SD card mount/unmount errors. While the device is on, removing the SD card results in its contents being marked as “read-only”. Note: The card itself is not write protected. This issue can be fixed on a PC, but it recurs each time you remove the SD card from the device.
Project save freezes unit. This only occurs during unsuccessful SD card unmounting/mounting. Instead of receiving the SD Mount Error 136, the unit freezes while attempting to access the project folder on the card.
Assign MIDI CC and Automation MIDI CC ignoring incoming MIDI data. This happens despite debug showing that MIDI is being received by the unit successfully. All settings are correct and this worked on the previous firmware version. Note: MIDI CC Thru still works.
Screenshots only capture LEFT screen, but duplicates the output so that there are two screenshot image files. This one is pretty self explanatory.
Reformatting the SD card or rebooting the device does not permanently fix any of these issues.
Interesting. I upgraded back to 1.14B to test this. 1/3 of my definition files triggered this error: “Syntax error line 84”.
If the error refers to the definition file itself, Line 84 of the definition file contains nothing but “33”, since it is a placeholder for future CC definitions. This is similarly iterated over several more rows all the way up to 127, so… I don’t know.
The only thing different about the three files is in the title. The one that triggers the error contains a symbol in the name, as evident in these pictures. I don’t know what programming language you use since everything ends up being saved in those custom .dat formats, but this reminds me of a programming language getting an update that changes the syntax, triggering errors in old code that doesn’t fit the syntax change.
Update on #3, it looks like only the currently selected track in the automation menu will record incoming MIDI CC. Any tracks in the “background” do not record incoming MIDI CC data when it does work. Which I guess is intended, but being able to record on all tracks would be nice.
Well technically, that’s non compliant The parser expects a number and a name.
I keep iterating on the parser for the definition file, with what vague “spec” we have in mind, so it makes sense this “non-standard” syntax broke.
A workaround for now would be to add a dummy name like “_” to these placeholder lines
I could add a case to ignore this sort of “unnamed” parameters, so that it behaves like before.
Please keep the explicit error, the less odd special cases there are, the better it is for everybody in the long run.
I’ll take this opportunity to thank you for the error checking on Hapax instrument definitions! On the Pyramid it was always a lot of unnecessary headsctraching to find your own typos.
It can be frustrating of course, but it’s a one-time self-inflicted speed-bump: none of the examples contain such syntax so it was relying on undocumented behavior to begin with.
And to be clear, this isn’t directed to @DrowninginReverb in any way. Just speaking from long experience of dealing with similar quirks in other software.
Fair, haha. Maybe it would be good to add a small note about this in the definition file section of the manual? It might help save some confusion even if it’s for a minority of users. Unless there already is one that I missed.
Hello there! Was playing with the step mode sending drum events to Ableton Live via USB device, and at one point the Hapax just froze, I think when I was adding a new event while playing (and sending clock information + 2 tracks content at the same time). I’ve not been able to reproduce that issue yet though. It happened with the last beta firmware of course.
I have been able to reproduce my issue VERY consistantly now. If I load the Hapax, with default settings, and try to set the track 2 in drum mode, then go to the step mode, write a few events even without playing anything, the Hapax freezes. It happens also with the 1.14A, but not with 1.13.
And better supported with the new cv range setting
The parser expects a number and a name.