where did you get these numbers from? did you make them up?
first you go "bruh bruh bruh" on me and then you drop this. couldn't
you at least look around a bit?!
since when has OPZ been clocked at 4MHz? who said that it does?
the chip's been designed to run at NTSC colorburst frequency, damn it!
on top of that, you didn't have to make up anything. AT ALL.
fixed frequency is simpler than eating with a fork. you just write the
frequency IN HERTZ (!!), the block and that's it.
really? were these numbers necessary?
oh man....
specifically the bottom line with "length/step-length/delay" and the associated buttons -- previously would just get cut off when there wasn't enough room, now scales the elements to fit (uses a table)
* extend "autoMacroStepSize" setting to include an option to set the horizontal scale in the macro view based on the longest macro (of the current tab). this means that you'll have a consistent horizontal scale across all the macros, rather than changing for each macro. existing options are unaffected.
* in "single" macro view, i noticed that there was no way of knowing which macros were actually being used (i.e. non-zero len) without selecting each of them individually and then trying to remember. so i added a len readout per macro to the listing.
* add undo to instrument editor (check for diffs on the current DivInstrument in insEdit, record them in a stack)
* style fixes
* accidentally left some logs in
* typo in style fix
* cheat to avoid warning -Werror=class-memaccess on linux
* warn instead of assert on case where MemPatch application would exceed size of target buffer (which should never happen, if you're applying the patch to the same type it was generated from)
* instrument editor undo: don't check delta if no user input has come in that could potentially have dirtied the editor
* don't run a delta against cached instrument if not insEditOpen
* revert fixedQueue to before my 'fix' (if i touch it again i'll add unit tests)
* explicitly cast to (DivInstrumentPOD*) when memsetting DivInstrumentPOD in DivInstrument constructor, rather than relying on implicit memory layout
* use delete[] instead of free (whoops)
* MemPatch/DivInstrumentUndoStep -- remove clear() function (ambiguous whether it should free data, it only existed to set data to null after the swap, so just do that directly now). Also set data to null after delete.
* DivInstrument -- fix dangling undo-step pointers being created on duplicate (potentially leading to use-after-free), fix undo-step objects being shamelessly leaked
---------
Co-authored-by: Adam Lederer <adam@adamlederer.com>
* Create android.yml
* bug fixes part 1
* bollocks number 1
* Update android.yml
* why are you crackling you arent supposed to do that
* stop crackling please
* what a load of
* what a load of part 2
* what a load of part 3
* what a load of part 4
* final commit... i hope!
* final commit my rear bottom
* final commit for real this time
* Delete .github/workflows/android.yml
* Update sysDef.cpp
AArt1256