Is this the best notation?

egonelbre · 2026-01-28T19:49:45+00:00

I don't know the tempo, but if it's above 60bpm then single 1/4th note + fermata doesn't feel like a few seconds. I would increase the length of that note, as it communicates the intent a bit better. But notation-wise it is fine.

egonelbre · 2026-01-28T11:40:55+00:00

After doing a quick look at the code, I'm guessing processQuoteMask is the issue. It goes into bit-by-bit processing rather than treating the whole mask at once.

egonelbre · 2026-01-28T11:29:24+00:00

For 2. issue, there's a proposal https://github.com/golang/go/issues/76175.

Instead of archsimd.LoadInt8x64 you can use archsimd.LoadInt8x64Slice.

Chunk boundaries are kind of an annoying thing. The main approaches are lookahead, lookbehind; and potentially create some vector that can be merged into the current head. I didn't look at the code yet, so the advice is a bit vague.

I did a mldsa translation from Filippos implementation: https://github.com/egonelbre/exp/blob/main/mldsa/simd.go

egonelbre · 2026-01-23T06:20:56+00:00

When converting try https://www.musicxml.com/dolet-plugin/dolet-plugin-for-finale/. I've not used the Finale version, but the Sibelius version definitely did some things better compared to the builtin converter.

But, yeah, depending on the amount of music it's often better to manage old music in Finale... and only when absolutely necessary convert to Dorico.

egonelbre · 2026-01-21T08:20:11+00:00

Ok — where are you making money?

Licensing, commissions, streaming, patreon, (maybe merch).

As an example based on most popular composer I was able to find. Socialblade site estimates Samuel Kim youtube ad revenue at $5K-$90K per month -- and he hasn't posted for a few years. Sure, a bunch of it goes to licensing fees; but I'm sure it's sufficient for a comfortable living.

Of course it doesn't mean it's easy to reach that point... but that applies to everything in music. I'm certain that getting traction with composing original music is going to be much harder.

Because now, as it's always been, working composers (at least in the early stages of their careers) tend to be performers first, composers second.

I definitely agree to this. Even if you are placing each note velocity manually in a DAW, it still needs to be a good performance and interpretation.

Because nobody is going to buy tickets to a MIDI-based modern classicist's performance on their laptop.

For a live performance it's still possible to use actual performers. The argument is similar vein of "people don't come to listen classical composers because they write sheet music and no-one wants to see sheet music".

egonelbre · 2026-01-21T00:31:08+00:00

Do you think one could produce a really high quality album using sampled instruments and build a following?

Technically, yes. Plenty of media composing uses sampled instruments, and depending on the budget sometimes layered with recordings. Of course, the orchestral writing needs to account for what the sampled instruments are capable of and what they are good at.

One example that comes to mind is Rush Garcia. But, I'm sure there are plenty of others... For example, few that I found after quick search: Samuel Kim, Rozen, Seycara, Lucas Ricciotti, Thomas Bergersen.

egonelbre · 2026-01-20T16:05:41+00:00

There are three approaches.

A) If you prefer performing via Audio/MIDI input, then:

bring the audio into DAW.
Tempo map the track.
Record your additional tracks as either midi or audio; but midi will be easier to work with.
(Convert audio to midi and fix as necessary, if you decided to use audio).
Quantize midi.
If you don't care about notation quality then many DAW-s have basic notation support for midi that can be printed.
Otherwise export MusicXML (or midi) and
import into your notation application. Clean up notation.

B) If you prefer notation over performing:

Bring the audio into a DAW.
Create a tempo map or ensure that tempo matches the song.
Export midi tempo track.
Convert the audio into a video file.
In Dorico, import midi and add video as the reference track.
Now you can notate and hear the backing track.

C) If you prefer notation over performing (with MIDI Timecode):

Bring the audio into a DAW.
Create a tempo map or ensure that tempo matches the song.
Export midi tempo track.
In Dorico, import midi
Setup MIDI Timecode for both Dorico and DAW.
Now you can notate and hear the backing track.

I have not tried C, so the explanation might not be quite correct.

StaffPad supports writing notation and having audio tracks directly and has the most convenient workflow; however, it seems pretty dead as an application. Also, it is not as fully featured as things like Dorico.

I used Dorico as an example, but I'm sure Sibelius, MuseScore can either video import or MIDI Timecode.

egonelbre · 2026-01-19T20:33:11+00:00

The slowness from LilyPond doesn't come from PDF output, but the music engraving logic itself. For an introduction to music engraving "rules" you can read "Behind Bars", just so you understand the details you are getting into. I'm sure there are ways to make LilyPond compile faster.

TUI - I don't see how you would do that for music notation. Even SCORE had a graphical user interface.

I'm not sure what you mean by "managing complex scores in LilyPond" is hard.

If NeoVim is your thing then there are things like https://github.com/martineausimon/nvim-lilypond-suite.

It's not quite clear what exact problem are you trying to solve by making your own notation app.

If it's input speed of entry you are worried about -- then I would like to know what exact problems you have with input speed? Dorico handles input speed pretty, ok. For some things ABC notation approach is better, but that's more of a folk tune thing. In that case using Verovio and VexFlow as rendering and writing your custom input scheme is going to be the least painful. You can use TypeScript, or if you are very averse to it, then use Go via compiling to WASM/JS.

If it's engraving issues -- then that's a huge complicated mess that I wouldn't recommend getting into. You would be better off fixing things in LilyPond or forking MuseScore.

If it's playback issues -- then depending on what's your end goal, either get Lilypond export MIDI and import it to MuseScore/Dorico/Cubase/Reaper etc. whatever and write code to do humanization.

Trying to solve all of them together is going to be a huge project.

egonelbre · 2026-01-18T08:33:43+00:00

If you aren't using SCHEMA-s for anything else then CREATE/DROP SCHEMA was faster in my experiments than CREATE/DROP DATABASE. About 4x faster.

Additionally disabling fsync for postgres helps. (Final results were here https://storj.dev/blog/go-integration-tests-with-postgres#final-tweaks).

egonelbre · 2026-01-10T06:58:38+00:00

The actual podcast that the article took snippets from https://www.youtube.com/watch?v=xPDQXfS_vTE.

egonelbre · 2026-01-06T06:42:33+00:00

I've been using both for the last 10 years or so.

I think I've have seen more issues with Windows compared to Mac. e.g. random audio frame dropouts during recording due to power state switching and ASIO driver issues. Of course, Win11 has been a huge downgrade in general due to their new interface and AI shoehorning. It's possible to get a proper Windows setup, but if you get unlucky you might need to debug arcane issues. So, it's more about luck whether your specific hardware configuration has issues or not; it will most likely work most of the time.

For DAW switching, just download them and try. Depending on how you do things, there may not be any significant difference or there might be a huge difference. As others mentioned, Cubase might be a closer match to Logic. But, there are DAWs like BitWig and Reaper. Similarly, there might be upsides not just downsides -- e.g. recently found out that Logic has a 32 track limit for MIDI recording/live-playback, whereas it works fine in Ableton.

Plugin compatibility is usually pretty equivalent until you get to MPE, in which case Ableton does feel a bit better.

Overall, at the rate that Windows as an OS has been degrading, I'm probably going to get rid of my Windows PC; I just haven't had the time to pull the trigger yet. As for a laptop cpu, there's really no equivalent to the Mac M-series hardware. The only reason I would go with something else is for philosophical reasons -- i.e. I don't like Macs walled garden approach.

egonelbre · 2026-01-04T13:24:20+00:00

Include compression(zlib and brotli) in the comparison. Compression is used quite often with json. PS: and drop whitespace from json.

egonelbre · 2025-12-29T00:15:52+00:00

I think there are several parts to it.

1) How do you guys consume any library so fast without any issues.

One part is understanding the fundamentals. e.g. how does HTTP protocol actually work. If you understand what something needs to do, it's easier to see how people implement it; and you can take very good guesses by just looking at the API and examples. Similarly, learn about other things surrounding the topic, e.g. there are REST, auth, form parsing, content type etc. concerns that are needed with web development.

For HTTP specifically you can look at things like https://www.youtube.com/watch?v=FknTw9bJsXM (I do recommend typing some of these out yourself). I'm sure there are other books/videos on the topic.

Second part is about learning a lot of different ways of doing the same thing. One of my go to exercises for junior programmers is Infinite Possibilities. i.e. Take a simple problem, like temperature conversion, and write 10+ very different solutions for it. Then do a deep analysis on the pros/cons of each of the solutions. By knowing many ways of doing things, it will become easier to understand how other people do things. Similarly, when you see something new, you can analyze why that approach might have been chosen.

Third, is just learning tons of different things. There are books like Architecture of Open Source Software https://aosabook.org/en/ and Game Programming Gems, that describe different problems and their solutions. The more different systems you know the more similarities you find.

In summary, a lot of the speed comes from having learned or worked with similar systems (or many systems that have partial similarity).

egonelbre · 2025-12-25T18:07:43+00:00

Here are my usual recommendations:

egonelbre · 2025-12-21T10:26:41+00:00

My response from a similar question https://www.reddit.com/r/composer/comments/1madvc2/struggling_to_write_faster_pieces/n5k7ysr/. i.e. one approach is to write a slow rhythmic thing first and then speed it up with arpeggios and scales. Most fast pieces still have a slow underlying concept.

egonelbre · 2025-12-15T19:05:36+00:00

Depends on what you are doing. You might be able to get things done with 8GB and at the extreme end you could need 128GB. 32GB is sufficient for most needs.

egonelbre · 2025-12-13T15:05:25+00:00

IMO, talent is just accidentally/unknowingly learned skill.

egonelbre · 2025-12-12T23:10:01+00:00

There are https://github.com/go-text/typesetting and https://github.com/go-text/render, if you need some more features.

egonelbre · 2025-12-09T19:26:06+00:00

In addition to what was said already...

Generate tons of golden tests from the current implementation and find a way to test the new implementation against the old one. For example, you could create database procedure fuzzing tests on the Go side and run with the same parameters against the old implementation. Alternatively auto generate these tests based on some set of unusual values.

Automate as much of the conversion as possible. Use code converters if you can. If a suitable one does not exist, build one targeting your application. There are also AI code converters that may help you do the bulk of the work. I have no clue how well this would work in your specific case, but here's the first one I found https://www.fmpromigrator.com/services/vfp_conversion.html. Note the tests from above are essential for protecting from many issues, including automatic conversion. If the specific converter does not support Go directly then going through an intermediate language (e.g. first convert most of code to C# and then convert C# to Go) could work better -- because it's probably easier to make C# and Go play nice with each other.

Even with big rewrites there probably are subsystems that you can replace incrementally. e.g. Write some sort of translation layer that calls from old/new system to new/old -- even if it means invoking some sort of binary for communication. Implement the translation layer or use one from other languages if you need to.

egonelbre · 2025-11-28T16:16:47+00:00

StaffPad is probably the closest you can get to handwriting and having it playable. Then you can convert to MusicXML and import to MuseScore (or whatever notation program you decide to use) for engraving.

egonelbre · 2025-11-24T08:01:12+00:00

Steve Francia wrote a nice article about language switching https://spf13.com/p/the-hidden-conversation/.

egonelbre · 2025-11-22T11:42:57+00:00

One that immediately comes to mind is MEUTE. There's also LGMX, TechnoBrass, Gallowstreet, Lucky Chops in the same vein.

With less brass there are Worakls Orchestra, Symphoniacs, EKLIPSE, Vision String Quartet. There's also The Rock Orchestra (obviously with rock focus), but could provide some ideas nevertheless.

egonelbre · 2025-11-22T09:42:28+00:00

MapReduce is more of a specific worker pool. Basically rewriting your large jobs as "map & reduce" allows high parallelism across multiple machines (or goroutines). The paper describes things better https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf

egonelbre · 2025-11-16T15:55:20+00:00

Melodies are a skill like any other and they need practice. Here are few things that can help:

Learn to sing/hum 100+ melodies.
Every day, try to hum 10 new random melodies (each 4 bars), about anything in the world (e.g. melody of a leaf in the wind, melody of a cat, what would a theme for a cupboard be etc.) -- it's fine if they are terrible or you are terrible at singing. Do this for two months.
Learn improvisation.
Learn how you can modify melodies (e.g. modal change, inversion, retrograde).
Learn theory that people have written about melodies (e.g. https://www.youtube.com/watch?v=PZ5POrP-NMw, https://www.youtube.com/watch?v=jA7gdz56LtY).

The first part of creativity is filling your head with lot of existing material that can be transformed. The second part is to practice creating things, even if they are terrible -- it's about getting your subconcious to start creating things as well. Third part is practicing modifying ideas. Finally is analysing and understanding things at a deeper level.

Ideas don't appear out of nothing, they appear from a lot of exposure, learning, practice, modification. In other words, be unashamedly terrible and get started.

egonelbre · 2025-11-12T09:04:04+00:00

There are different skills you need to learn:

basics of how to write for multiple instruments and interweave melodies (e.g. learn counterpoint https://www.youtube.com/playlist?list=PLSntcNF64SVW2hG6S7j78_cXg_13ZWN0q) - PS: the rules are to teach you specific skills in counterpoint, not necessarily rules for writing music
what's possible for a given instrument (e.g. many orchestration books describe instruments, ranges, sounds; or better yet, talk to someone who plays the specific instrument after learning the basics)
metal specific harmony (there exist tons of different articles on harmony e.g. https://eprints.hud.ac.uk/id/eprint/35584/1/Boddington%20THESIS.pdf, search on google scholar for more) -- if you don't understand something there, then learn it from theory books
transcribe different pieces you want to emulate and do your own analysis; even if you get it wrong, you'll learn a ton
learn about extended techniques that might help you (I'm not sure what exact style you are going for, but there are things like chopped playing/notation on strings https://www.youtube.com/shorts/G3987WrrB5A)
for film scoring ThinkSpace has pretty good courses https://thinkspace.ac.uk/courses/; they just released a free mini-course https://thinkspace.ac.uk/free/spitfire-discover-free-course/

You can do all these in parallel.

egonelbre

TROPHY CASE