I was looking at the infamous spritesheet for the textures for devices and whatnot (textures.png), and I was curious of the purpose of having every single knob, slider, and parameter translation as a separate sprite altogether. Doesn't this take up space in the code? I mean, I'd imagine that even though the Audiotool team is small that there must be some sort of modularization going on to chunk each bit of code per developer to help the process go faster. But, in any case, I can't help but feel this takes from processing that could be used for more complex concepts.
If each individual device was a seperate .SVG rather than all devices in one .PNG spritesheet, couldn't you overlay the respective fonts and parameters in their places? Under this criterion, the default parameters could be in an .SVG spritesheet, each one-a-kind, so they could be translated by the code, rather than... this
NOTE: the .SVG idea has been touched on before, and would solve problems like a https://www.audiotool.com/board/feature_requests/clean_font_option_it
But I think there was something regarding the complexity of its implementation, but I couldn't find the original topic... so rip in piece
Comments (2)
Nvm... on closer look I see why this is true...
Perspective
That would definitely be something to look forward to.
@andremichelle correct me if I'm wrong, but would it be possible to scrap the texture sheet altogether and use code to create devices? I'm not sure if this would help at all... but I know it's something I've done with a code project I did once. I took a lot of design inspiration from Audiotool and it uses solely JS and CSS.
Note, it's not really good because I never finished it, but I ought to. It'd be a lot of fun