Closed mat1jaczyyy closed 1 year ago
this isn't output device anymore this affects fade and output now the Initialize() method is flawed entirely and is probably what's causing most Output bugs and on 1.8.2 the launchpad fps preview in preferences crashes on click it's just that fade only cares about listening to the project's bpm, so it isn't as volatile with errors initializing anything like this is a suuuper bad idea since this gets run at the time of the device being constructed, the device cannot have any idea about what state its in the only time this initialize code actually does its work properly is when the project is loaded, since they all fire after everything is set up but when you're working with a device thats constructed or cloned rn due to a undo/redo/duplicate/new device etc, you can't know anything about how it will be used, so can't initialize, and trying to initialize will get it wrong half the time then you'd need to have an event on every single action in apollo like we have for projectloaded right now, but that would be absolute aids to implement so the correct answer is to get rid of this initialization altogether and implement it some other way so i don't know what to do
maybe by checking for init stuff whenever midiprocess is called if it won't be too expensive this idea won't work cus what if some track gets moved around before a note happens to hit an output 🤔 although maybe if we fire a stopsignal throughout the entire project every time an operation happens (which is extremely aids to do - UNLESS i force the clear every time the undo history updates, which might actually be big brain since every relevant operation has an undo entry), since midiprocess will never be called on devices that arent in the chain they won't ever initialize and will be dead as they should be. (this is idea 1)
idea 2
new class: EventDevice: Device {
contains HashSet called pool
w/o duplicates (referenceequals for comparer)
pool will contain all EventDevices (fade and output will extend it)
instead of each device subbing to project-wide events like they do rn, have a static EventDevice.Event(/* arguments */)
method which will notify everyone in the pool that something happened
everyone in the pool has their own implementation of what to check for (fade, output distinction), check if disposed then dont do shit
in undohistory: dispose eventdevices early
kinda feel like this gives us the same problem but a lot more explicitly...... i wanna try idea 1 first
hardcore idea if these 2 ideas aren't enough: separate data from processing. each device now has its own data object associated with it. in undo history, other data storage etc, store only the data object, this way when constructing a thing, construct data if only need to store data without it activating a processing engine in the device (the initialize bit subbing to the project), construct processor and feed it data if we're putting this inside the pf this is a lot more hardcore and will lead to a lot of boilerplate code
how long will it take to fix
long considering tetris has taken over my life unexpectedly
bruh
Output is buggy as hell. Should do this one from scratch