Testing loading documents in the video…
Crikey that was fast!
Wow, that was the fastest implementation of a hard to implement features I’ve seen in a long time!
Of course this currently doesn’t set the dirty flag for the workspace for every action it should. So I cheated after all.
Anyway, now playing with this it’s clear having the feature is great, regardless of it indicating 100% correctly there are unsaved changes! 😉 To solve the issue about Quitting with unsaved changes, I simply always at quit save a workspace document to the app settings folder. Not ideal, but better than nothing etc. Eventually of course the dirty flag notification will be everywhere where it’s needed. I also put in some bechmarks for measuring how long it takes to save the document, and as suspected it’s fast, often under 10 milliseconds. So optimizing for not saving when the whole save isn’t strictly needed doesn’t appear to be crucial. Loading however can take up to 1 second and probably more, as 3rd party VST plugins may be slow to instantiate, loading sound files may take time etc. While I showed loading the workspaces while the playback was on, it won’t work properly (the playback will stutter) for anything like live performance, there’s mutex locking of the whole audio engine going on when the workspace files are being loaded and I don’t think I’ll be doing anything particular for that in any immediate future. (It would probably be a major rewrite of lots of the code, just to serve some corner use case.)
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.