I thought it might be a good idea to write a blog-like thread where I record what I'm currently working on. I don't know if this is a great idea and if I find the time and motivation to keep this alive for long.
Most of this will be quite techy or boring but maybe you find some of the information interesting.
Comments (238)
I can't speak for everyone, but I'd definitely be interested! Maybe it might shed light on what is like and give people a greater appreciation for the platform and the developers behind it.
I don't know if Audiotool has some sort of (small) office or if all the work is done remotely by you guys in different parts of the globe. If the first is true, I've always wondered what a day in the life is like, so to speak.
What happened so far? In the recent weeks I developed a prototype (play a stereo sine-wave with start/stop via the app) of the audio-engine in Rust (programming language). Since yesterday this works fine as Booster AND as WebAssembly in the browser. Most work so far was writing the interface to the existing app. Because of the language switch I cannot re-use much of the existing code.
The whole today was dedicated to skim through the https://www.audiotool.com/board/feature_requests and https://www.audiotool.com/board/bug_reports boards. Feature requests are more fun (ok, less annoying ;) because they normally have more information readily available.
We currently have over 150 tasks in our tracker but lots of requests haven't been completely reviewed, yet. This will take some more days to close the gap.
I guess I'll stop in an hour or so for today.
Tomorrow I'll start to implement the device's tree (document) which is mainly the backend of what you see in the app.
I'll have to talk to the others about what internals I'm allowed to talk about. At least to respect their privacy. I don't want it to make too easy to hunt us down if the servers are down again ;)
Fun fact: I just found out I cannot reply to feature requests and bug reports of users that are blocking me. I can only close them. Not sure what to do about that :)
Thanks for this initiative! I'd also be glad to follow this.
I'm currently trying to figure out how we can make the Booster functional in Firefox. It currently refuses to connect because of security concerns which don't apply in our case.
This turned out to be frustrating ... again. The least awful solution so far would be to introduce a dialog where the browser places a security warning the user has to sign off. The booster would have to generate a self-signed certificate which introduces a lot of dead freight for an audio engine.
I'll have to rethink this.
The launch of the new front-end (bugs and feature requests) and some users not obeying simple rules ate a good amount of my time today. I spent the most part of the day in the forums and continued to validate feature requests and bugs.
Tomorrow I hope to proceed with my development plans.
i like this.
Same! It's just eating my time today.
Is there a source to this big issue?
Translating the structure behind the existing Java implementation is way more time-consuming than expected. I'm still writing the framework for the in-memory representation of the interconnected devices you see in the app.
I have a solution/draft that should be fast as hell, but it's hard to automatically generate code for that and the structure feels rather confusing.
Haven't had a lot contact to the other devs today but they were extremely busy in stabilizing the latest release.
Quarter to weekend here.
Yesss!!!
Super excited!
Yesterday @mbelow and I worked long hours on generating the audio document's structure into the Rust implementation. We finally succeeded but we also found a good number of to-dos in the existing implementation.
For relaxation I wrote about 160 test cases to make sure that a critical component won't fail on certain edge cases.
Today I mostly tried to tidy up the Bug board a bit. Some people seem to think we have more time to fix their bugs, when they duplicate existing reports.
Tomorrow we're gonna talk about the 200 open tasks/bugs/requests and how we want schedule them.
Issues of the day: Publishing broken, Booster misbehaving, 404 pages
@mbelow made the "downvote" functionality more visible and I hope more users will help the moderators to de-clutter the boards
@andremichelle
are all previously "linear" interpolation automations now going to be curved, or is it something that you can turn on and off as another interpolation option?
This sounds fun actually. Im interested
I finally got back to do some development stuff and together with @mbelow we made great progress. I'm now working on the transmission of the audio document between the main application and the audio engine (de-/serialization).
I tidied up some (lots of) code and now I'm struggling to get it back to normal operation - the tests will tell me when I'm done.
Have a nice weekend altogether!
How do I become a developer?
you don't
the developer becomes me?
You contact team[at]audiotool.com and not with a simple letter saying I want to be a developer, but with your full description and skill set.
Never Mind. You clearly disrespect AT terms & conditions when it comes to sample upload, yet you want to be a developer. The track on your page can get AT staff under a lawsuit case. Someone who cannot read, cannot become a developer.
i like how right after you said that he deleted the track lmao
I don't want audiotool getting a lawsuit. How do I delete samples?
No worries. Samples will be banned, and your sample upload privileges taken away.
shit
One question: given that the document stores all actions needed to recreate it from a blank project, is history part of it? If so, are bugs like this one: https://www.audiotool.com/board/bug_reports/exclude_cue_audio_source relevant to your work with it now?
I'm working on a far end of the chain so my part of the code receives the full document in a pre-baked form as a starting point. I'm not sure if the previous stages have to deal with the reconstruction of the history, though.
But thanks for your hint!
@mbelow
@andremichelle
@chordofdestruction
I know not only me but a lot of other people would appreciate a video file of you guys!
I know you have a lot of ur plate, but you could post a little video thing of AT behind the scenes.
How all those engines you are coding look like! No sensitive code or info of course.
You all could film a little piece of that "world", montage it all together in one video.
That would be absolutely awesome!
*on your plate
Thanks!
I like the idea. But since we are mostly working from home these days, you'll have to wait until the three of us meet in person again.
Martin, no need to complicate. Just pull out your phone and film some of your stuff here and there. Hey so this is what I'm coding, this is how it looks like. Other devs do the same, and stick those video materials together in one piece. So some of us can see not only imagine, what your workspace looks like.
But sure I can wait. Will be worth it.
P.S notifications are broken :) Not receiving them for last 4 hours
Andre and me are still busy fixing bugs. The most frequent ones we are seeing these days are timeout issues when loading the app. That's not surprising, given that some of the files needed to run the app are really large. Yesterday, we released an update that hopefully improves caching of those files, so that they are only loaded once and then stored in the browser cache. You may be able to observe this by slightly faster loading times.
Apart from that, Andre is babysitting @sandburgen 's new dog and is also beginning to optimize user interface performance. This will be done by offloading the rendering of the desktop to the GPU (graphics card), which in turn should give us more CPU time for audio processing. Unfortunately, it is always tough to predict how much those optimization will buy us in the end, so let's hope for the best!
Thanks for your interest. We already talked about something similar.
I fear the video might shatter the picture of how people think we're working :D - I'd first have to tidy up my desk - should be done by 2020 :P
One step back, two steps forward.
I re-furbished some code and the tests tell me nothing is badly broken (any more). 5744 lines of generated code successfully compiled so far - yay!
I'll complete the missing cases tomorrow and we're planning that @mbelow will help me to run some tests to make sure it's compatible with the existing implementation.
Reading the audio document's structure into the new engine will be fast as hell - but I cannot tell if this is noticeable within the rest of the loading process.
Note to myself: use "fast as hell" more often.
gotta go fast as hell
Maybe this is the right place to write down the primary goals of rewriting the entire audio-engine:
=== Stretch goals (not promising anything!):
(6 and 7 are my personal goals I really, really, really want to have!)
So excited for all of this! in regards to #8, are there any plans for ASIO support in any shape or form? I made a feature request a while ago but haven't heard anything.
There are no plans, yet. This is just an idea I'd like to implement. I guess ASIO has licensing issues we'd need to check first.
Ooo, by #7 do you mean macros? That would be insanely useful
No, I mean "use the LFO of a Pulv to modulate the frequency on a curve" by dragging a cable.
Ah, that's interesting. I can't visualise it, though I'm certain it would prove useful
Point 6 would be a pre-condition for this feature.
Having a standalone LFO module is something I considered writing a feature request for the other day, having all synths be semi-modular sounds like better approach to this in the long run but I can't imagine how much work would have to go into that
I agree with you, 6 and 7 are really cool goals. They remind me of the whole "modular DAW" approach of Bitwig, where the modulations can be "everything into everything" mind boggling.
jesus
Dude, this is interesting
:(
I finally managed to load an entire track into the new audio engine (Hooray!).
I had a bit of a trouble with my implementation using too much memory (stack overflow), but this has been solved.
Next big step: building the infrastructure where the new devices (synth and effects) will live in to produce music. First victim will be a tone matrix as a "Hello World!" implementation. I guess this will take several iterations.
Tech and nerd warning ahead!
Hail to the compiler! I just found out that it's possible in safe Rust to access circularly addressed arrays without any boundary checks and I'm totally excited about that! Less checks mean more performance and smaller binaries.
You can have a look at the assembly code of this https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=e7d73668e01b523da344cd1c1285ff3b (switch from "Run" to "ASM") but wash your hands after that :P
I'm going to use this construction to implement the cables between the devices, wave-forms and other stuff.
This also works for slices and Vec if we help the compiler a bit: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=6d5ee3eabf29c83f769c94ac809af5b2
Not as ground-breaking as for arrays but still a noteworthy optimization for some situations.
Wow, that looks great!
Omg, yes. This is beautiful in every possible way
I'm -often- approximating curves in automation regions with series of straight segments because I don't want just a linear transition. This would be great to have.
Great work!
I can imagine how this new feature has lots of dependent updates throughout the app. Just noticed that the preview lines on the region box itself are still linear :) Also, this curved interpolation will be especially interesting in tempo automation for very smooth, gradual changes.
Woow.. :O
I don't have anything to show that is nearly as cool as @andremichelle's work but I've got a basic version of the Tonematrix running: it plays the notes of the matrix which can be altered in the app.
Next step: make this approach more generic.
i made a thread about it https://www.audiotool.com/board/chitchat/show_the_things_you_did
How hard would it be to send and receive waveform data between devices, and how would that data be laid out?
(Sort of a continuation/rephrasing of what I asked in the topic "synth things")
https://www.audiotool.com/board/chitchat/synth_things
The data outputted by the oscillators, how is it formatted and how is it sent along?
So it shouldnt be too hard to implement custom oscillators for a new synth. I have a technique for synthesizing custom oscillator waveforms that I have been working on in my free time if you by any chance want to check it out.
You input two files of of wave data, it divides them, and normalizes the result, it is currently written in python, but it, in theory, shouldn't be too hard to adapt it to JS and the way data is set up in AT, I will get you a link to the code as soon as I can
I only have the technique made, I do not have an oscillator that uses it yet. The code can be found here: https://github.com/HealthyTrade/divinator/tree/master
I don't get the analogy, to be completely honest (does this mean Firefox supports Web-GL now? or has this just been implemented in Chrome to some capacity? or has the path just been paved in the code with some minor refactoring?)
In any case, this is super exciting and I can't wait for this. I think I have noticed lag when more devices are in the desktop that seems to exponentially decrease when the view is zoomed in, showing less devices. I don't know if that's related, but still. Fast is good.
Ah, that's awesome. I am very excited for this and will definitely be following its development here.
Huh, https://www.audiotool.com/track/ngwojm1qkhs/ isn't remixable and I tried to access the snapshot via the track API but the URL, https://api.audiotool.com/track/ngwojm1qkhs/2/snapshot.jpg doesn't work ;c
I'd love to see what you're working with
I'm honoured! https://www.audiotool.com/user/apollo/ i can invite you to a remix if you like?
Sure thing! Would you mind me posting a screenshot here too?
yeah thats cool man :)
just invited both of you
Got it, thanks!
Lol, I can already tell how great this update is going to be.
"Rendering document" is taking quite a bit of time...
Haha just wait till it has to load the samples
Why'd you have to jinx it?! Ahh
It's so laggy, that it took a fair bit of time for that to even show up.
I was able to (on a very low framerate) navigate the track a bit before the dialogue box popped up
Oh god, what computer do you have? Jesus...
Mine sounds like a jet engine trying to run this and I can't wait on these samples to load ;c
Firefox takes 110 seconds to load - which is fine. Chromium is still loading ... ... ...
...
...
Ok 20 Minutes to load with Booster and you can hardly recognize the song XD during playback. I'll take this as a challenge for the new engine.
@andremichelle I was just panning and zooming using the scrollwheel on the mouse. I'm not sure what you mean by the line-break though
I'm unsure if the new graphics rendering engine will take advantage of programmatically textured devices using something like SVG rather than the current sprite sheet style PNG texture implementation (which obviously shows visual degredation at high zoom levels).
Also, for the record, I prefer the project notation you used here for this in particular (e.g. [Project Name]) and keeping all minor developments in the same comment.
Coloured cables could be useful, if you find the tinting that doesn't make them look confusing. Maybe you could use the timeline approach for colouring regions: all cables are initially created with the default colour, so you maintain a clean desktop. A context menu allows the user to colour a cable. So it's up to the user how their desktop will look.
@jordynth you know, I was actually thinking about that, thanks for reminding me. I meant to mention if coloured cables don't look right, perhaps a bright braided-like or accented style might work better. Or, perhaps a simple lableable cable tag could work for even a better workflow. Just some alternatives to consider.
I'd mostly use this to quickly identify inputs along the top of the Centroid. I often extend the mixer and since I always place devices under it, all cables going into it overlap, so it's confusing to see which is which. I don't think I'd colour many cables. Just a few for reference. So a solid, maybe not very saturated colour would be enough.
Ah, I see what you mean. I can confirm that the browser zoom level was at 100%. I had Chrome Developer Tools open and took a node screenshot of the HTML body element. So that window, being opened to the side, shrunk the available viewport width.
I'm thinking that's what caused it.
Ah, I see. I didn't think about the aspect of shading and the visual intricacies audiotool devices have. Though, I did attempt to replicate this in an old project of mine which would've been an audiotool-like device built entirely on CSS/SVG. But it makes sense for audiotool, in the long run, to try and decouple visual and computational processes to take full advantage of the device's speed capabilities.
@andremichelle that looks really cool. A new opportunity to both expand functionality and emphasise the app's character.
Yeah, I'm ngl, that is pretty nice. And I agree with Jordi, it could also definitely help workflow too
I saw that velocity bars now have MUCH more usable handles. :)
@andremichelle I think it's a huge improvement! They've always been far too small. They are a little big now but it's much better.
Would be a really good chance to sneak in a new device there.
can anyone tell me how this sounds https://www.audiotool.com/track/gsnqnt0f
Stop spamming my wall and other peoples' threads!
don't post that stuff here, this is for dev updates dude
oh my bad idk im just tryna get known but my fault
Wow
I wonder how this will impact performance on chromebooks, seeing as they dont have a GPU.
Fair point, and a reason for concern for me as well.
I just checked some random CPUs that are in use (https://en.wikipedia.org/wiki/Chromebook#List_of_Chromebooks). All of them have an integrated graphics acceleration unit. It's always better to use that than the CPU.
It seems that I have the weakest machine among the devs regarding the graphics power, so we'll use that to make sure you don't need gamer hardware to use a ToneMatrix ;)
lol ok
thanks for the consideration
I like how the curve looks on that picture
This is exciting
I'll take your whole stock
that's pretty dope ngl
Yes
cough cough whisper whisper m o d u l a r * sneeze cough whisper cough*
Summer holidays? xD
Yes, in a way :)
Didn't forget about this thread.
is this still going?
yes :)
Will try to give it an update in the upcoming week.
Today I crawled through the https://www.audiotool.com/board/feature_requests board and gathered all website related entries (from the recent 10 months) to identify some hot-spots and relate duplicates.
Regarding the audio engine: next up: timeline automations, samples and waveforms.
Why did this die out?
Known as I is not Known as him anymore or there is nothing much to share?
An unhealthy mixture of laziness and too much work.
Is there a thin chance that you're a CIA agent?
Maybe no.
Soo ... I'm currently helping out to bring that redesign to production. There's a lot of work behind the scenes going on. Lots of legacy code to be pruned.
The first release will bring us a changed site structure and better™ help boards. The most important change will be an improved mobile experience. This is also meant as groundwork for long outstanding feature enhancements.
We also strive to cut down some upsy-daisies with that approach.
maybe :D
I hope that fixing the daily server issues is a priority. Producing has become very difficult lately.
vvv i can second that
I try to reduce the complexity of the website. Therefore I aggressively deleted lots of now irrelevant bug reports. Mostly very old stuff where we were waiting for feedback, Flash-related bugs, and bugs caused by temporary outages.
I also want to merge some of the boards. Some of them feel rather dead and lots of users don't understand the role of the production boards. This results in lots of unnecessary moves of topics.
BTW: if you feel the deletion caused any collateral damage, please let me know.
Still reviewing bug reports - only 170 left :/
There's a lot of garbage in there, making it hard to keep track of real problems.
And we're hunting down some server stability issues. We just found the cause for the nightly unavailability. Let's see how to fix that...
I did it. I reviewed over 1000 bug reports to make sure we're tracking everything that is of any relevance for future improvements.
I deleted lots of reports, which originated in temporary server outages to not attract necromancers. I also removed everything related to legacy stuff (pre WebGL, Flash, old website).
Well done man, thank you so much! :D
my heart D; </3
lol, its fine, its just alot of stuff is kept from users, so we come up with theories, some are bad and some good
I have been frustrated for a while about the lack of major updates recently (since next), since I didn't have answers, I assumed it was something along the lines of the team being too small, and audiotool not being profitable enough to expand the team. I believed this, because I saw the how not great the servers perform and saw the income from patreon, wondering how this can support multiple people and a website. I believed the servers are not great from the lag there is to post a comment, to the constant need to refresh. but from what I can gather from this thread, the teams focus seems to be on fixing bugs and fixing old code, with occasional minor feature added, such as colored cables and curved automations, would this be correct, are any of my theories correct, is this too weighty of a question to ask, is this rude, I don't mean to be rude
crap does this come off as entitled
There isn’t really any way I know ofto say what you’re trying to say without coming off as entitled
Hi there. Valid question(s). The servers are beefy enough to handle the load. It's some old (Website) code that brings all of that frustration you've been experiencing.
I just want to let you know that we're really unsatisfied with the current situation and are working hard to make things better - I mean really better!
At the moment we have to decide whether to invest our time in fixing the existing website or work on a new solid base settle those problems in a professional way. The pandemic situation doubled the load on our machines which makes rarely occurring problems more frequent. Another problem is that most users are hitting our servers on times where the team is asleep or on weekend.
Regarding those smaller updates: Not every dev is able to fix all kinds of bugs or implement all types of features. Everyone is specialized at least to some degree. So while there's a lot to improve on the website for example, some devs are more efficient for this specific task. Whenever someone gets blocked on their work, they tend to implement smaller things that are fast to complete.
We have huge plans (Website and Studio) but our team is just not big enough to deliver that in short-term. Whenever we implement something big - there will be a long dry spell.
Hope this sheds some light onto our work. So, we're not dead, we're just invisible from time to time to do necessary works below the surface.
Maybe I'll have to post here more frequently to make our work more perceivable.
thank you for shedding some light on this
@chordofdestruction Hi there. Maybe you could share a minute and post some interesting info in this topic. Would be interesting to know what is happening latelly behind the scenes. AT has been struggling with a lot of errors especially the one where you publish a song and it crashes. The song is published tho, but there is no info on assets. What has caused such a major issue which seems not to be an easy fix since it is happening for couple weeks now. Thanks in advance
I believe pandemic has been harsh on you guys too. Slowing the " mood " and things down. Best of luck
in the long run polemics hits us harder
@sandburgen I was not trying to be rude.
No I meant world politics not your comment :)
Oh I thought for a second thwt I sounded polemic. All good :)
Status of the new engine: I have kind of a Tonematrix and the TB303 makes noises.
I managed to load Ollie's Tripwire ( https://www.audiotool.com/track/ngwojm1qkhs/ ) without a crash (really - just loading). This track is a challenge because of its size and complexity.
A preliminary tempo automation is working as well.
I'm working on the automation tracks (loops, region, etc.) right now.
The engine should now be able to load(!) all tracks without an issue. There's still a special case for microtunings which I have to fix.
Control automation is working fine. The master volume of the stereo-output can already be automated.
It's also possible to add and re-wire plugins at runtime now. (I'll have to check if deletion is a thing already)
Next step will be to complete the implementation of the StereoOutput (limiter and stuff).
Other automation types (Notes, Patterns, Audio) should follow soon.
ToneMatrix now sounds like the original version.
BitCrusher is now complete and one can play with all control during playback.
Next device will probably be one of the Delay-devices to have a test case for audio buffers.
Tonematrix can now be edited without reloading the track.
Delay stompbox is implemented and is working fine.
An internal change: there will be multiple versions of the engine - one for each sample rate. This improves ergonomics for the implementation and performance. I hope I don't regret this choice.
What's the behavior with samples of different sample rates in the same project? Is there an internal behind the scenes conversion?
Sorry for the late response.
I'm sure if the current implementation does a conversion while loading the samples or just reads them in a different speed to adjust for the deviating sample rate. I'd expect the latter because that is necessary to enable pitching.
But that has nothing to do with the aforementioned change. The sample rate of the playback device has always been fixed during playback.
I'm working on the translation of the Pulverisateur (yay).
So far I translated the code 1:1 (which is a lot!). Now I have to transform the structure into something the new engine likes.
So far the polyphonic control (incl. glide/slide) is complete. Next will be the oscillators to have something audible to test.
Midi integration is complete (it's easier to test a synth this way).
I can finally play some boring sine waves on the pulv, but they don't stop voluntarily rn.
I guess the amp-envelope would be the next logical thing, so the notes don't play forever.
The amp-envelope basically works - modulo a few minor bugs.
Decay-looping is implemented but requires some testing.
Found the bug. Amp-envelope is now fully functional (including the decay-loop).
Next up: make oscillator 1 sound non-sine-ish
Except for the waveform, osc1 is working now (panning, tune, octave, level, master level).
Waveform is now complete as well.
Now that Osc1 is fully implemented, Osc2 and Osc3 will be next.
After that Noise and AudioIn will follow
Is it band-limited? Also, will oscillator sync and noise be band-limited as well? (I think only the 3 oscillators were).
I mostly leave the current implementation as is.
The oscillators themselves are band-limited.
The sync isn't and I'm not sure if there's a sane way to implement it.
What's the purpose of band-limiting the noise? It isn't prone to aliasing in my opinion.
Osc2 and Osc3 are working. Need to implement Sync and Kb-Track to complete them.
Thanks. I was wondering if this translation of the code would be used as an opportunity to implement improvements to the DSP. I know that the Heisenberg was rumored to need upgrades (mostly band limiting as well and improvements to the waveforms), or the issue with Slope's 10K cap in high pass mode. You're right that noise probably doesn't need extra band limiting. The generation mechanism probably implements it already.
No changes to the devices are planned for the first release. Some minor improvements for previously undefined behaviour or extreme cases are ok in my opinion. Non-audible changes are ok as well, if they improve internal stuff.
The Pulv's noise-source is complete now (except for a combing issue which should be easy to fix).
External Audio Input is also available now.
The filters will be next.
Sync and Kb-Track are working fine now.
was anything new just implemented? Or did something go horribly wrong at AT HQ?
disks died in a database server (holding the board and newsfeed)
Ah, ok. I thought maybe the AT staff partied too hard and knocked over the server racks on accident.
i am a production addict and when audiotool is updating for a day i start to get ideas.
do you guys do your own hosting for certain services? no s.m.a.r.t. monitoring either?
@trulsenstad multiple disks died at the same time without S.M.A.R.T. giving us any notification in advance. Maybe a faulty hdd firmware or spikes in the power supply. That's what backups are for ;)
Little big News: Pulv is complete!
I also did some tests with the new engine running in the browser. Looks good so far: no glitches and very good latency (for a browser). Performance could be better. WebAssembly likely behaves different from what I expected. I have a working profiler. As soon as bigger tracks can be played I'll have a look at the bottlenecks.
We're looking into a way to make this available to some testers, so we can get early feedback.
If y'all want to help: please try out the "Worklet only" mode (Chrome only rn) and let me know if there are any issues. This is going to be close to the operational mode of the new engine. Watch out for glitches and latency.
details see: https://www.audiotool.com/board/news/new_audio_drivers
Pulverisateur inside out - this is a block chart of how I implemented the module.
@chordofdestruction oof, that sounds like a potential nightmare.. Happy to hear you guys keep good backups though!
I suddenly get 5 times more respect for audiotool developers
I finally found the tattoo for my back
Got the first numbers for multi-threaded audio: Up to 10× speed for certain scenarios but I think there's room for more (not for every draft or machine ofc)
How many cores on the cpu were there that you tested on?
1 to 20. The test case was bad for more than 10 cores. As soon as I have a better test case, this should get better.
little big planet
Would this theoretically scale with CPUs that have higher core counts? Or would 10 be the upper limit of what it could utilize in its current state?
Genuinely curious, since my current CPU has 6 cores, and I'm looking into getting a new one with either 12 or 16 cores sometime kinda soon, depending on what happens.
Mine has 12 cores (24 threads) and that's just a normal value for a recent AMD machine.
You can use as many cores as you like but at some point it doesn't scale anymore. There's some overhead for deciding which thread has to do which part. For me 20 threads performed worse than 10 threads for some loads.
I personally don't think that 10 is the upper limit, but I'll have to wait for a real-world application to see how far I can get and if it's worth the time I have to invest.
The pulv has a built in limiter?
I'm currently working on the timeline control (seek, loops, stop at end, show playback position). I think this is the last missing piece to make the prototype easier to test.
That and allowing to edit things in the timeline without requiring a reload (should do this next)
wssp
I'll assist Martin a bit with the redesign so he can concentrate on the important stuff.
I have the honor of finalizing the wave-forms. The most complicated thing will be preventing riots a wrong shade of blue may cause. Let's make it rainbow colored, so everyone is happy.
Lol you could just make it a gradient of blue as well, if that's not too complicated.
So then there's all the rights and wrongs as far as a blue may go, lol.
Always a good read: https://en.wikipedia.org/wiki/Bikeshedding
Hey, I wasn't trying to be an ass or anything, if you posting that was implying any frustration as far as me bringing up a gradient of blue might have brought about, lol. I was just genuinely expressing that I thought it'd both be cool if you did use a gradient as well as also jokingly bringing up it filling in "the rights and the wrongs as far as blue may go" and all. Not saying you posting that was anything like that or anything, just thought I'd express my idea on the matter in case I did cause any frustration. I understand what you're saying though, the color/look of a waveform is a fairly trivial matter when compared to all the larger plans you're working with, I also understand that it's stressful dealing with people who don't understand what you're dealing with as a dev/moderator and all, but you know. Just wanted to clarify a bit. Either way, I do agree, that is a good read, thanks for bringing it to my attention.
All cool - sorry if that came out wrong. It's just good to recognize when a discussion enters the "bikeshedding zone" so that nobody gets offended when the devs decide to overrule people for economic reasons.
I'm still open for suggestions - I just don't want people to expect me to evaluate and comment all of them.
We don't have gradients (other than shadows) on our entire site, so I believe they would look out of place. But using different shades is totally an option. I'll just experiment with some ideas and we'll see where we land.
Oh yeah, I definitely understand that, no worries. Yeah, I was just making sure I didn't piss you off or anything lol, I didn't realize that I didn't word things very well with what I'd said before until you replied, so I was a tad worried. I guess that's just one of those things about text conversations rather than face to face, it's easy to misinterpret things. Oh but yeah, I definitely understand not wanting to set an expectation or anything like that. Sorry for the confusion, you're cool dude. That about gradients definitely sounds about right, whatever does end up being the final product I'm still looking forward to seeing what you guys decide on regardless. Keep up the good work guys.
Oh wow I never actually realized there aren’t any gradients
i miss the early 2010's gradient themes
fun with colors
more
Holy heck they're awesome :D
And I think the font got changed a little bit imo
Unfortunately, some users like me can't pick the right one, haha. What about changing the gradient settings in our preferences?
I'm just kidding. gradients and multiple colors might look good on their own, but they have to work with the entire page design.
Preferences are too much work rn.
Another intermediate state
With distribution of dynamics
Smaller context
Removing wild and color and adding mirror (doesn't look as good as expected)
Oooo pretty
Current state (higher bars mean louder, taller bars mean more dynamic)
Those last few are pretty cool.
Very cool stuff fo' sure. How does it work though? How are you able to read the waveforms and project them like that? Quite curious.
ooh that current state looks niiiice
excited about this too!
@neon_trc250 The script receives a series of "loudness" (rms) info of the track. The rest is some math (median, etc.) and graphics.
I think I'll go back to a version where the waveform starts at the bottom. This way louder tracks always appear brighter which is more intuitive.
Yeah, that's probably the best way to go about it one way or another. Maybe if there's a way to specifically define the edges at the top, that would look nice.
I think this could work
Not too different from the old waveform but way more details. Not final, though
I like it honestly, it's pretty nice. I like how it's as compact as it is, giving it as much detail as possible for the space it's given. That and the general detail per bar is also very nice.
Last one is great yes
oh my god that's beautiful
oh, and now there's some auto-leveling, which moves the average loudness to the vertical center. This way you can see more details on very loud or very silent tracks.
Niceeee. That'll be useful.
Oh hey, are you planning on changing the mixer display in the bottom left at all? Not that there's any reason to, it's already fairly neat. I wonder if I'm the only one who uses it lol.
Uh - what mixer? The visualizations?
Sorry sorry yeah, the visualizer lol, my bad.
Auto-leveling will be useful, good idea
Can't wait to see the update
Thanks for putting the joining dates of users in full, the "joined about xx years ago" was slightly frustrating ;)
where?
Mh, it is on the users' profile, but I don't see it on yours... Maybe it's a glitch, it works on mine, saw it on my old accounts as well and a bunch of other people
everyone including you has the "about a year, about 2 weeks ago" for me
Now I see yours
2014-07-10
strange. well i remember that being a feature on a google chrome extension. maybe you are running that?
Nevermind, you're right this is Audiotool downloads indicator that apparently does also that
Yes, this is a " side product " of AT download indicator extension.
This looks so familiar, a MAX/MSP user here.
It would be cool for some users to be able to switch to this " simple layout ".. we could make much larger projects without all these visuals that need to be rendered all the time :)
nice idea
yep, less lag. Not saying I am GOD level pro at MAX but this is very familiar, been tweaking around with it for 2 years now.
After the look updates on portal side, is the "studio" still in progress? The audio quality has deteriorated significantly. It seems that everything sounds with extra stereo filter and the resonance is very bad. Frequencies are absurdly out of control. Is it by any chance a desired downgrade? Please Administretor and Staff, please help me move my comment to the correct link and support location. Please, the aesthetic and user friendly aspect is ok, but the audio quality is the first requirement as well as the supreme priority of a music platform. Thanks.
no changes have happend in the studio that should trigger such massive issues.
"should" - in theory, at least.
and please kindly post your issues in https://www.audiotool.com/board/bug_reports - thanks!
I can't confirm this behavior.
On the bright side, now we can see the exact date a track was published
Neither.
Why has there been a lot of AT maintenance lately? Is something new coming here?
I'm guessing it's the new location of the app