[col_rad]

It's still not for sale.

I sent the last prototypes to a couple of Beta Testers (Actual Composer/Music Producer, no Youtubers) and took their feedback to make a lot of Hardware/Software improvements.

If you're a professional Music Producer and want to test a Prototype, just send me a mail via the website.

The next batch of Prototypes, planed for EoY, will be a bit bigger, to get even more feedback and there are a lot of requests from reseller that want to try it out extensively (Thomann for example). I'll also have to do a new EMI/ESD check (hopefully the last one)

As I said in another comment, I aim to have a Batch of 100 ready for sale around May next Year. But lets see how this plays out. Hardware is hard ;)

[jacquesm]

I know hardware is hard (I've built a bunch of electronics for machine control and in the dark ages of IT electronics was my bread and butter). These days I'm active as an investor and consultant to investors as well as with my own music related project (pianojacq.com). If I can be of any use to you let me know, email is in profile, I've just subscribed to your newsletter. I'd love to see this project succeed.

[follower]

I took a quick look at pianojacq.com and can relate to the sentiment you expressed with "I wanted to concentrate on making music, not on endless runs and other boring ways of practicing"--although in my case it relates more to creating new music rather than performing.

Interested to hear more about your experience with VexFlow if there's anything more to share on top of it being "very nice". :)

I think VexFlow was one of the projects I encountered when I was recently looking for musical score rendering solutions for a somewhat non-typical context[0].

In the end I settled on using a Standard Music Font Layout (SMuFL) reference font directly rather than a higher level engraving library which led to a result that was...mixed. I share (a.k.a. rant about :) ) my experience more toward the end of a HN comment[1] in case the topic is of interest.

[0] A 7-day game jam entry created with Godot 4: https://rancidbacon.itch.io/stave-off

[1] https://news.ycombinator.com/item?id=35139269

[jacquesm]

VexFlow is kind of tricky to use but extremely versatile and probably saved me a year (or two) in getting pianojacq.com up and running but I am still in the process of optimizing the code, last year during a holiday I did a complete refactoring to make it all more readable and I still have a plan to re-work the interface to VexFlow into something nicer than what is there right now. The problem is that there are 6 different representations of the score in memory right now (midi, VexFlow, visual (bitmaps), timing (milliseconds), pianoroll (for the sustained notes) and finally beats and bars. All of these serve different functions and have to be kept in sync so the bookkeeping gets to be a bit ugly. There is yet another representation used to reverse from pixels on the screen to notes. I suspect every program like that suffers from a similar problem that in order to do things fast you need to keep it around in the representation that is most suitable for the problem you're solving at that moment in time. For instance, during midi decoding I don't have time to parse the whole data structure but I do need to know if a note is still sustaining.

Edit: I looked at your stuff, did you know about:

https://guides.loc.gov/music-notation-preferred-preservation...

[col_rad]

♥