https://ieeexplore.ieee.org/document/1674847 G. J. Vanderbrug and A. Rosenfeld, “Two-Stage Template Matching,” IEEE Transactions on Computers, Vol. C-26, No. 4, pp. 384–393, April 1977. DOI: 10.1109/TC.1977.1674847

Comments URL: https://news.ycombinator.com/item?id=49330246

Points: 11

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49221454

Points: 2

# Comments: 1

I've made a couple of music apps over the years, including one of the oldest JS music apps on the web, that also does URL encoding: https://pointersgonewild.com/2012/04/23/musictoy-music-made-...

But also generally, I was looking at other web-based drum machines, and most of them are either super basic, full of ads, or they have bad cryptic UIs. I also wanted to design a more advanced sequencer with a timeline that would have an intuitive UI to work with.

I built a sequencer in NoiseCraft, a browser-based music programming language I built a few years ago (e.g. https://noisecraft.app/101), but you can't chain pattern in this sequencer, which makes it harder to create longer piece (though people have found workarounds).

The app is live here: https://maximecb.github.io/groovie

The GitHub repo: https://github.com/maximecb/groovie

I'm calling it Groovie, and notably, it has a timeline view so you can arrange up to 32 patterns into a song. It has 150+ samples you can select from. You can adjust the panning and volume of each row individually. It has delay as well as an LPF/HPF filter and swing. It has the ability to send a MIDI clock signal so you can sync it with your hardware (Chrome only), and lastly, it works on mobile phones and tablets too. I designed the interface to be intuitive and to use fairly standard design language (I hate cryptic UIs).

The app is fully static with no backend, but you can share beats/tracks with others as they can be encoded into the hash part of a link, in a compressed format. It uses multiple tricks to try to shrink the data since many patterns are repetitive, sparse, or reuse data from previous patterns.

Since it's open source and fully static, it's free forever. You don't need any kind of account to use it. You can't upload new samples in the app, but I am very much open to accepting contributions (pull requests) for new samples, but they have to be public domain / CC0 / out of copyright. I would love to get more vocal one shots and more metallic sounds. One idea I had was to maybe sample old movies that are out of copyright.

For those who like to play with Claude Code, I added a "make a beat" Claude skill to the repo that will generate an arrangement based on your description and give you a shareable link. It might also work with other AI assistants if you point them to the skill (untested, let me know).

Let me know what you think. If anybody wants to share some patterns they create, I would love to add them as new examples in the readme.

Comments URL: https://news.ycombinator.com/item?id=49182903

Points: 4

# Comments: 2

It's easy to dismiss our efforts, but Ruby is just as dynamic if not more than Python. It's also a very difficult language to optimize. I think we could have done the same for Python. In fact the Python JIT people reached out to me when they were starting this project. They probably felt encouraged seeing our success. However they decided to ignore my advice and go with their own unproven approach.

This is probably going to be an unpopular take but building a good JIT compiler is hard and leadership matters. I started the YJIT project with 10+ years of JIT compiler experience and a team of skilled engineers, whereas AFAIK the Python JIT project was lead by a student. It was an uphill battle getting YJIT to work well at first. We needed grit and I pushed for a very data-driven approach so we could learn from our early failures and make informed decisions. Make of that what you will.

Yes Python is hard to optimize. I Still believe that a good JIT for CPython is very possible but it needs to be done right. Hire me if you want that done :)

Several talks about YJIT on YouTube for those who want to know more: https://youtu.be/X0JRhh8w_4I

YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle).

That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).

And I went into some more details the talk I gave at RubyKaigi 2023: https://www.youtube.com/watch?v=X0JRhh8w_4I&t=2404s

On the flip side, YJIT is probably one of the most memory-efficient JIT compilers out there (for any language). I say this having spoken to other JIT implementers.

We've worked really hard to reduce the memory overhead and at Shopify it's now down to less than 10% in our flagship production deployment.

Regardless, if memory usage is a legitimate concern for you, you can very easily remove the Rails initializer that turns on YJIT. You can choose between memory usage and response time. The choice is yours.

I only take calls from my mother when I feel up to it. The reason for that is that she has no concept of boundaries. Her mental illness prevents her from grasping that concept. Her default behavior tends towards what a normal person would call harassment. If you can't relate or understand a situation like that, it might just be because you've had a relatively safe, coddled, privileged life.