I usually use it to edit audio tracks quickly up to 10 minutes long, though I have received nice emails from people who have used for 1hr+ podcasts successfully (though certain heavy operations wouldn't be very fun to use).
For multitrack sessions, there is the ability to export to a .amss file that contains all the settings, markers, tracks etc. For single track edit... it would just crash right now. There is already a feature for caching audio tracks in indexeddb (it's under >File), but honestly it's not a web api I have found to be super reliable. I don't blame the browser developers, because I 'm sure if it was more reliable certain websites would put it to use storing gigabytes of trackers on the user's machine :). For this reason, I haven't made it auto-save the session automatically yet, trying to be a good citizen on the user's computer, maybe that will change in the future if there's a strong need for it.
Also, right now there is no backend, once it loads there are no more requests made to the server, so it's bound to frontend limitations. This is by design, I want it to be an app that respects users, doesn't upload or leak information, no ads, etc, even if it means getting a small hit in functionality in other areas.
I think of it like photopea/pixlr are to photoshop. Quick and easy to use, get you at 90% of the way. If somebody wants to do a serious operation, then by all means go for a paid desktop pro-daw solution :)
i managed to load a 12 hour book. it took some time to load, but once loaded the UI remained snappy, so i guess it is usable. the only problem is that the waveform does not scale when i zoom in.
Did you load it into multitrack, or the regular editor? (in multitrack it does not scale currently, but working on it). On regular editor it should in theory try to zoom.
There is a pyramid cache mechanism for long files, basically it tries to optimize with simple heuristics how many peak-lines to show for every zoom level. The renderer is pretty dumb right now - just old-school 2d canvas "ctx.lineTo" calls - no gpu, so enormous files can really make it slow, this is the reason for the drops (to ease load).
So it might be dropping way too many samples in this case and then not switching properly to the next cache level because the zoom to duration/length ratio is enormous.
I usually use it to edit audio tracks quickly up to 10 minutes long, though I have received nice emails from people who have used for 1hr+ podcasts successfully (though certain heavy operations wouldn't be very fun to use).
For multitrack sessions, there is the ability to export to a .amss file that contains all the settings, markers, tracks etc. For single track edit... it would just crash right now. There is already a feature for caching audio tracks in indexeddb (it's under >File), but honestly it's not a web api I have found to be super reliable. I don't blame the browser developers, because I 'm sure if it was more reliable certain websites would put it to use storing gigabytes of trackers on the user's machine :). For this reason, I haven't made it auto-save the session automatically yet, trying to be a good citizen on the user's computer, maybe that will change in the future if there's a strong need for it.
Also, right now there is no backend, once it loads there are no more requests made to the server, so it's bound to frontend limitations. This is by design, I want it to be an app that respects users, doesn't upload or leak information, no ads, etc, even if it means getting a small hit in functionality in other areas.
I think of it like photopea/pixlr are to photoshop. Quick and easy to use, get you at 90% of the way. If somebody wants to do a serious operation, then by all means go for a paid desktop pro-daw solution :)
edit: reason
i managed to load a 12 hour book. it took some time to load, but once loaded the UI remained snappy, so i guess it is usable. the only problem is that the waveform does not scale when i zoom in.
Oh, that's fantastic to know.
Did you load it into multitrack, or the regular editor? (in multitrack it does not scale currently, but working on it). On regular editor it should in theory try to zoom.
There is a pyramid cache mechanism for long files, basically it tries to optimize with simple heuristics how many peak-lines to show for every zoom level. The renderer is pretty dumb right now - just old-school 2d canvas "ctx.lineTo" calls - no gpu, so enormous files can really make it slow, this is the reason for the drops (to ease load). So it might be dropping way too many samples in this case and then not switching properly to the next cache level because the zoom to duration/length ratio is enormous.
I 'll look into it. Thanks again