Rendered at 06:02:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
kirbysayshi 5 hours ago [-]
looks at code, sees safety closures, function assignments, sequential var declaration
Ahh I see you are one of the old ways, of the lost knowledge :)
I am very nostalgic for this style of development, even though I do not miss it in a team setting at all!
Super cool app you’ve made!
fagnerbrack 11 minutes ago [-]
Let's make it modern again, just write a blog post on <famous-company> tech blog
JKCalhoun 6 hours ago [-]
So want something like this but where the tracks are in the cloud.
I want to "check out" someone's drum loop and add a guitar riff. Check it into a branch.
Someone else checks out the drum+guitar, adds a bass line. Checks in.
"Jamming" with other people is one of the most fun things. To the degree that you can "get close" on the web…
RiffHub, anyone?
notThrowingAway 11 minutes ago [-]
Out of all web-based apps I've tried, audiotool matches your description the closest.
esikich 2 hours ago [-]
Idk if the GitHub analogy really works for music.
With software, the code is a tool. And you can give the code away and still make money on hosting, support, enterprise sales, consulting, recruiting, whatever.
With music, the stem is the product.
If the drum loop is mediocre, nobody cares. If it's actually good, the creator usually wants ownership, licensing, royalties, exclusivity, or at minimum, attribution. But even at that level, it's trivial. Once you remove the triviality of it, it becomes art, which is the product.
People absolutely want cloud collaboration though. Shared sessions, async recording, version history, stem exchange, all of that makes sense.
But public forks of high quality musical material don't really compound the way software tools do. Most musicians are not trying to maximize downstream reuse of their riffs by strangers on the internet.
16bitvoid 5 hours ago [-]
Bandlab Studio, maybe? Never used it, but might be what you're looking for. There's a web version and a mobile app.
Bandlab is decent enough for this, yeah. It's not "version control" in the way that programmers are used to, not by any means. More like "Google Docs" but for a DAW session. Certainly good enough for "my brother who plays keys lives in a different city but we want to collaborate on something".
pantelisk 3 hours ago [-]
I think this git but for music you are suggesting is quite interesting (or more like a figma for music maybe).
My musician friends still use dropbox and google drive to push around files to each other. Honestly, I would be all for it but I have a feeling that musicians are a tough crowd when it comes to these services. So maybe if somebody like Bandcamp who has already demonstrated good will with the community steps up and builds something that would be a delight.
sporkl 6 hours ago [-]
I think that's what Soloist[1] is trying to do (unaffiliated, but I've met the founder)
That doesn’t look similar at all. That looks like an app for making loops on your phone.
someguyiguess 5 hours ago [-]
Yes. I’ve wanted something like this for a while. I’ve always wondered why there isn’t version control for DAWs. So many times I’ve spent hours editing a track and accidentally saved it without specifying a unique file name. Only to open it later and wish I could go back to before the changes that fucked it up.
empressplay 2 minutes ago [-]
Logic Pro allows you to revert to previous saves / auto-saves.
PaulDavisThe1st 4 hours ago [-]
The good version controls used for code & text are line-oriented; most DAW session file formats are semantically scoped, and so the VC tools won't work well.
Most DAWs allow you to "snapshot" a session at any time, and return to it as you want to. Certainly Ardour does that.
antoniojtorres 3 hours ago [-]
That reminds me of what Splice used to do
ajs1998 5 hours ago [-]
Could be pretty easy to do with atproto accounts. Users could save/share their music as a tangled.sh repo and other people could contribute or fork as they please. A nice UI could hide all of that and make it fun to collaborate on music.
Too bad I'm lazy. RiffHub looks neat.
mickmister 1 hours ago [-]
[dead]
cocodill 2 hours ago [-]
It feels like cool edit pro 2 before it was turned to shit by adobe. Your app has a pretty good and intuitive UX. And that's the most important thing in an audio editor.
sam1r 5 hours ago [-]
Significant props for accepting .flac files out of the bat. Incredible work.
serious_angel 8 hours ago [-]
It seems like the inspiration went from Audacity, and with great changes to the design and feel of calmness and solidity!
I've tried loading a file with XM format, yet the current state of the import logic stated "Unsupported". Is there any chance you'll support the format?
For example, the following artwork is radiating charmingly in VLC:
- https://cable.ayra.ch/modplayer/mods/!Others/DYNAMITE_-_Winamp_5.0RC8_crk.xm
And, thank you! very much for the experiments, effort, miracles... art you do...
pantelisk 8 hours ago [-]
Thank you :) I 'll look into it, I am a little cautious of bloating up the filesize (right now it's at 98kb of js and 10kb of css), but if I can make something work efficiently I 'll give it a go.
On an unrelated note, I'm a little surprised there is no good open source web audio tracker (like Renoise but for the web) out there yet...
Oh.. I 'm mindblown! I was wrong, this is the great tracker we were missing
dspillett 6 hours ago [-]
For that much functionality 98kb is hardly bloated at all by modern standards, impressively slight in fact, it could probably cope with some more.
Unless part of your fun is keeping it so very trim, of course!
pantelisk 6 hours ago [-]
Yes, it's part of the fun. Original version was 65kb (with just the single editor mode and all the filters, mp3/wav export etc). But then having to add flac codec, tempo estimators and finally the multitrack mode, made it closer to 100.
When I started developing I was a little frustrated with how bloated the web felt back then so I took that direction, it's much better today though and it's no longer an issue, but I still find it fun to impose these constraints and try to work within or around them (there's this fascinating concept of constrained creativity)
jamwise 5 hours ago [-]
I appreciate the attention to efficiency and avoiding bloat. As a frequent audacity user I'm thinking I might end up using this for a lot of simpler tasks.
That said the web offers such great techniques to maintain this. Passive loading of plugins for example could keep things snappy and light and load things when you need them.
If you want the perspective of a prospective long term user: I'd be very comfortable using your app even at tens of megabytes. You could probably keep your initial load pretty light but pull in larger modules as needed. There are certain effects and audio layering I often use in Audacity that would keep me there, but your modern interface and browser access are huge selling points. If your vision includes moving to a bigger editor I guarantee you you'll find a huge base who wouldn't even notice megabytes of code.
pantelisk 4 hours ago [-]
All very good points, not much to say I agree with you. With loading plugins on demand it could grow in size without affecting load and experience (and since offline mode is a separate link that would still be fine to be a little larger since it's fetching the app locally).
sgallant 7 hours ago [-]
This is great. I need to do audio work this coming week and was dreading Audacity.
timc3 6 hours ago [-]
Try Ocenaudio - I’ve used pretty much every audio editor free and paid for and this is my go to for a free editor.
I also cannot understand why anyone would recommend Audacity.
hootz 5 hours ago [-]
Ocenaudio is closed source, that may be one of the reasons someone might recommend Audacity over it.
jrm4 5 hours ago [-]
Hehe ditto
I get flak for this, but Audacity is my "proof" that GIMP's name is why people don't use it, not the UI.
Like GIMP, Audacity's UI is awful, but people still use it. :)
em-bee 3 hours ago [-]
people use gimp too. and i bet there are more gimp users than audacity.
as for the UI, i don't get it. what's so bad about it? and how is this one better? i looked at both and ardour too. so far audacity is the only one that has a feature to detect silence and label it. it's pretty easy to use too. i use this to detect chapters and create a chapter index for audio books. last one i did this week took only a few minutes, and most of the time was typing the chapter titles into audacity. i could not figure out how to do this in ardour or audiomass
throawayonthe 7 hours ago [-]
when have you last tried audacity? it's been getting friendlier
amelius 7 hours ago [-]
How much work would it be to compile Audacity for the web?
Agreed but it’s still not a proper DAW and suffers from those limitations. It gets very rickety when you go beyond a basic stereo mix.
Kaliboy 7 hours ago [-]
Have you tried Ardour? It's like a superset of Audacity.
gunapologist99 44 minutes ago [-]
Is this open source? No license.
algoth1 7 hours ago [-]
Getting the 2002 Cool Edit Pro 2.0 vibes!
keithluu 4 hours ago [-]
Awesome tool. Is this the a new version? I used this few weeks ago and it looked a bit different.
shuaibird 3 hours ago [-]
Looks cool. It feels like an early web-based Logic Pro-style editor.
djfobbz 4 hours ago [-]
This is a very impressive undertaking. Great job!!!
genericacct 8 hours ago [-]
Very nice. One feature id like to see is import of stem bundles as produced by various tools like suno or stemsplitter
ugh123 7 hours ago [-]
Is there midi support and vst support? I know that's asking for a lot =)
RobotToaster 5 hours ago [-]
Doesn't seem to support midi currently unfortunately. I was hoping for the same.
ZeWaka 6 hours ago [-]
Not sure why you remove the tooltips from deactivated buttons
vandyswa 6 hours ago [-]
What's a waveform box and how does one select it?
pantelisk 6 hours ago [-]
It's the audio track in a channel. A channel is the horizontal strip, a waveform box is a piece of audio somewhere across that strip. You can double click on one to enter single editor mode, or single click to make it active (once it's active you can drag it around, apply effects to it, move it on a different channel etc etc).
There is a little [ + ] button next to CHANNELS in the sidebar, it has no limit but right now so add as many as you like :)
It's using dom to render the multitrack waveform boxes currently so I would assume after a certain point it might start to slow down a bit. In the future might switch it all to be webgpu based to avoid such limits.
6 hours ago [-]
argimenes 7 hours ago [-]
Makes me think of Quatermass ...
macwhisperer 11 hours ago [-]
this is cool thanks for making it!
yesbut 7 hours ago [-]
what is the theoretical file size / project size limit? what happens when the browser crashes?
pantelisk 7 hours ago [-]
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
em-bee 3 hours ago [-]
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.
pantelisk 3 hours ago [-]
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.
Ahh I see you are one of the old ways, of the lost knowledge :)
I am very nostalgic for this style of development, even though I do not miss it in a team setting at all!
Super cool app you’ve made!
I want to "check out" someone's drum loop and add a guitar riff. Check it into a branch.
Someone else checks out the drum+guitar, adds a bass line. Checks in.
"Jamming" with other people is one of the most fun things. To the degree that you can "get close" on the web…
RiffHub, anyone?
With software, the code is a tool. And you can give the code away and still make money on hosting, support, enterprise sales, consulting, recruiting, whatever.
With music, the stem is the product.
If the drum loop is mediocre, nobody cares. If it's actually good, the creator usually wants ownership, licensing, royalties, exclusivity, or at minimum, attribution. But even at that level, it's trivial. Once you remove the triviality of it, it becomes art, which is the product.
People absolutely want cloud collaboration though. Shared sessions, async recording, version history, stem exchange, all of that makes sense.
But public forks of high quality musical material don't really compound the way software tools do. Most musicians are not trying to maximize downstream reuse of their riffs by strangers on the internet.
https://www.bandlab.com/creation-features
[1]: https://www.soloistapp.com/
Most DAWs allow you to "snapshot" a session at any time, and return to it as you want to. Certainly Ardour does that.
Too bad I'm lazy. RiffHub looks neat.
On an unrelated note, I'm a little surprised there is no good open source web audio tracker (like Renoise but for the web) out there yet...
Unless part of your fun is keeping it so very trim, of course!
When I started developing I was a little frustrated with how bloated the web felt back then so I took that direction, it's much better today though and it's no longer an issue, but I still find it fun to impose these constraints and try to work within or around them (there's this fascinating concept of constrained creativity)
That said the web offers such great techniques to maintain this. Passive loading of plugins for example could keep things snappy and light and load things when you need them.
If you want the perspective of a prospective long term user: I'd be very comfortable using your app even at tens of megabytes. You could probably keep your initial load pretty light but pull in larger modules as needed. There are certain effects and audio layering I often use in Audacity that would keep me there, but your modern interface and browser access are huge selling points. If your vision includes moving to a bigger editor I guarantee you you'll find a huge base who wouldn't even notice megabytes of code.
I also cannot understand why anyone would recommend Audacity.
I get flak for this, but Audacity is my "proof" that GIMP's name is why people don't use it, not the UI.
Like GIMP, Audacity's UI is awful, but people still use it. :)
as for the UI, i don't get it. what's so bad about it? and how is this one better? i looked at both and ardour too. so far audacity is the only one that has a feature to detect silence and label it. it's pretty easy to use too. i use this to detect chapters and create a chapter index for audio books. last one i did this week took only a few minutes, and most of the time was typing the chapter titles into audacity. i could not figure out how to do this in ardour or audiomass
(I'm a bit behind on web technologies nowadays)
Sorry still working on improving the UX :)
EDIT: There's a short video here - https://x.com/pkalogiros/status/2053492761350046032
It's using dom to render the multitrack waveform boxes currently so I would assume after a certain point it might start to slow down a bit. In the future might switch it all to be webgpu based to avoid such limits.
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
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