(audiomass.co)
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?
You play over the most recent (eg) 16 bar repeat. At the end of each repeat, everyone gets the updated loop. It's easier to experience than describe but is surprisingly effective and bypasses a whole class of latency issues.
I recently saw a talk of the developer who basically bootstrapped this. Open source and all, and he talked about the idea of collaboration and showed some features and forks that sounded like what you want.
The talk: https://youtu.be/BD7jQcuUOaA
Edit: and another comment alerted me to the existence of live jam sessions, so this would be a possible extension of it
https://support.apple.com/en-us/guide/garageband-ipad/chsf2f...
Most DAWs allow you to "snapshot" a session at any time, and return to it as you want to. Certainly Ardour does that.
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.
Also I don't get the impression the idea is intended for "most musicians".
Too bad I'm lazy. RiffHub looks neat.
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
Far more intuitive, I think. Keyboard shortcuts and cutting and pasting similar to what you'd get in e.g. Word.
(I'm a bit behind on web technologies nowadays)
One question: I tried the "Fade In" effect; is there a way to control its timing (i.e. the part of the clip where the effect is applied) ?
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...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 'll be heading off soon, so decided to write some features included in this release that might not be apparent right away (still working on improving the UX).
- Drag n drop multiple audio files into multitrack = multiple channels automatically created
- Double click on a waveform box in multitrack, opens it in the original audio editor (for more precise editing)
- Copying (command+c, or shift+c) works between multitrack and regular editor. So for example, you can open a file in original editor tweak it, and then copy all or part of it and paste it in multitrack in a specific channel.
- Most effects have already pre-made presets to make them easier to use
- You can make your own effect presets by clicking the 3 dots after having made a modification in an effect (stored in localstorage)
- Zero crossing selection is under "Edit"
- There is a tempo tools section in View. You can automatically detect tempo of a track, tap to guess a tempo and play with metronome
- There is also an id3 tag viewer (for mp3 files) there as well
- You can right click or press M to add markers (makes it easier to highlight sections of a track, especially when working with longer audio tracks)
- Seamless Loop tool (under Edit): crossfade preview, silence trim, repeat loop, open loop in a new editor tab.
- Offline/PWA support: Help > store offline version, will open a new page that will trigger a service worker that will make the site work offline as well.
- Session export as .amss file for multitrack. If you aren't done working on a session you can export all of its audiofiles and configuration in an LZMA compressed container file (will still be pretty big though). For single audio mode, mp3/wav/flac export is available.
- Pressing X in multitrack when 2 waveform boxes overlap, makes them crossfade smoothly (denoted by an "XF" label at the top right - undocumented behavior but can be quite useful, will keep improving it)
- You can open the menu by pressing the ~ key and then navigate it with arrow keys (left/right for sections, bottom up for selections, enter to trigger an action and esc to close) for a tiny bump in speed of getting things done. Similarly the time controls are clickable and open a mini menu where a time can be specified to jump quickly to it (arrow keys to go between minutes/s/ms)
And finally my favorite feature of them all (though not a new one per se),
- In "View" select "Frequency analyzer" or "Multitrack mixer" and then press the dock button. Audiomass supports the ability to extract elements of it into new pop up windows. So you could have parts of the application on a different monitor keeping the main app in the main tab. It's a very old trick, but I find it kinda cool :)
Thanks again and hope you enjoyed the sample music! (edit: formatting)
As others on this thread have commented, you haven't specified a license. Don't jump on the first thing you think of. Consider the various OSS licenses and decide which one suits you best.
https://news.ycombinator.com/item?id=23337091
The author mentions in the thread that he eventually plans to have a proper license for it and needs to figure out the licensing of some of the dependencies, but that was six years ago.
https://news.ycombinator.com/item?id=23338538
This is not directed at the quality of the project itself, however, which seems to be good.
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