Interpreting sheet music images is very complex, and I’m not surprised general-purpose LLMs totally fail at it. It’s orders of magnitude harder than text OCR, due to the two-dimensional-ness.
Obviously it will depend on what you're doing and one's tolerance for things many deem to be annoying. I've encountered people with incredibly high tolerance for slow and awkward workflows but, alas, I am not one of them.
If I had to call out one thing it would be that you can't do tests without having a database there. This results in incredibly slow tests for even the simplest things. I don't need to test database persistence every time I'm testing some domain logic. So maybe then don't do fat models and "map" the data from Django models to a domain layer? Well, congrats, you've just manually implemented a data mapper ORM, which is what SQLAlchemy is.
It works well for simple CRUD stuff, which is really useful. But it very quickly becomes a mess and a big ball of mud when you start to do more complicated things. IMO a db access layer or web framework should be completely independent of domain logic, but Django makes that really difficult.
> IMO a db access layer or web framework should be completely independent of domain logic, but Django makes that really difficult.
That is an issue/features in Django, depending on your view. You really don't get to do things the framework doesn't want. If you're trying to fight the ORM or any of the components in Django really, including the Django REST framework, you're going to lose and have a bad time.
There are certainly reason why you'd want to separate domain logic from the database access, but then Django isn't what you want. You're also going to miss out many of the things that makes Django easy to work with, like getting most CRUD operations for free.
I don't fully understand your comment, but Soundslice has had first-class support for tablature for more than 10 years now. There's an excellent built-in tab editor, plus importers for various formats. It's just the ASCII tab support that's new.
I’m not super familiar with Soundslice. But all the tab users I know use guitar pro or maybe ultimate guitar, and none of them can read standard notation on its own. Does Soundslice have a lot of tab-first users?
Yes, Soundslice has a ton of tab-first users. And in fact the primary reason I founded the site was to scratch my own itch of being able to create tab that's synced with real audio recordings. (I'm a guitarist myself.)
When I read the blog post, I thought it was saying that Soundslice didn't have any tab support.
The comparison of "we expect this (classical notation screenshot) but instead got this (ascii tab screenshot)" made me think that the only thing Soundslice supported was classical notation.
Definitely a subtle distinction there. Soundslice supports tab in many formats (MusicXML, Guitar Pro, PowerTab, TuxGuitar, PDF/images of published tab, or tab notated directly in the Soundslice editor) but didn't support ASCII format yet.
I wonder if LLMs will stimulate ASCII formats for more things, and whether we should design software in general to be more textual in order to work better with LLMs.
I've had AI create ascii-art (Nethack-style) dungeon diagrams when I asked it to write me a D&D adventure. Last time I tried it these dungeon diagrams were completely nonsensical, but that was a few years ago.
I think ASCII art in particular is generally a weak point for LLMs; maybe they could do better if they used an image model. Other ASCII syntaxes using matched { } delimiters seem like they would be easier.
Just a quick plug: check out Soundslice. It's interactive sheet music with a ton of learning tools built in, including easy navigation, looping, tempo changing and transposition.
We've also got a scanning feature that does OCR for sheet music, to get music into our system. Plus there's a full-featured notation editor. A good overview is at https://www.soundslice.com/features/
Soundslice (https://www.soundslice.com/) is a fully baked version of this idea. Tabs synced with videos, with a full notation/tab editor and tons of built-in music practice tools.
Hi, I'm one of the creators of Django. For what it's worth, here's what I do for my product Soundslice (https://www.soundslice.com/). I've been working on it full-time for 12 years, so a lot of thought has gone into this.
Soundslice is very complex in its front-end JavaScript. It has an entire sheet-music rendering engine, capable of "responsive" sheet music [1], plus an integrated audio/video player for music practice, a full-fledged sheet music/tab editor [2] and a ton more [3].
In short: we don't use any JS frameworks. It's just vanilla JS — and in this day and age, that is totally fine for building a quality product.
We're disciplined in how the JS logic is structured, trying to find the right abstractions for the concepts of our app, and we use native JS/DOM APIs (which are full-featured these days).
Every web page on our site is served by Django — in other words, there's no single-page-app stuff. I've always found the idea of single-page apps to be "against the grain": it goes against how web browsers are optimized, and it goes against how HTTP/HTML were designed. Plus it adds a ton of complexity that mainly benefits the maintainers of front-end JS frameworks (it gives them power over you).
I think an entire generation of web developers has been misled into assuming JS frameworks are table stakes for building high-quality web apps — and that is 100% wrong.
The time-tested pattern of "serve the initial HTML (with Django or whatever), then add functionality with JavaScript" is solid and helps you build high-quality, maintainable websites.
On a meta note: for years I've sat on the sidelines and rolled my eyes at the frontend JS world, knowing it doesn't affect me or my product. But I've come to realize all web developers — including those who don't choose to use frontend frameworks — do indeed have a vested interest in pushing back against the bullshit. That's because the JS frameworks are making the web crappier, and that affects us all by giving the web a worse reputation. Sites load slower, UI is weird/buggy/non-standard, and the culture perpetuates (meaning it's harder to find developers who know "actual" JS instead of frameworks).
Inconsistent style. Once global functions (that's so 2000), once prototypes (that's so 2010). No lazy loading, no modularization, no state management. Mixing variable declarations with initializations, one "var" declaration in the code. He probably haven't heard about TypeScript, transpilation, and doesn't understand static typing. Fells like a show off. That guy is an absolute no-no.
Was going to ignore this comment until the last 2 sentences. I rarely come across sites / articles that do this good of a job at explaining something I think calling it a "show off" and saying the author is an "absolute no-no" is a bit rude and I don't agree with it either. If anything I appreciate the code as it is, it's very readable at least to me.
My comment was /s of course. JavaScript from 2000-2010 era can do wonders especially if you leverage modern APIs and enormous performance of modern browsers, instead of silting it up with transpilation, frameworks, and layers of modules. Unfortunately simplicity is signalling a beginner and amateur in enterprise working environment.
For much better results, use a custom trained model like the one at Soundslice: https://www.soundslice.com/sheet-music-scanner/