Show HN: Super Looper – Disco Sequencer App
superlooper.universlabs.co.uk
superlooper.universlabs.co.uk
In JavaScript, in particular if you're not using Chrome? Apparently just about impossible (I haven't seen reliable timing yet).
There are a lot of downsides to embedded Flash, applets, etc., but it's going to be a long time until the things that were possible with plugins a decade ago (including decent timing, and even plugging your MIDI keyboard in as an input for a application like this) are possible without plugins.
I have some faith we'll get there eventually; but it's a frustrating time during the gap.
i've implemented naive quantization and MIDI control in my own web apps, without plugins...
MIDI file parsing/writing/manipulation for js: https://github.com/kn0ll/midi.js
MIDI control for js (requires a server component, wrote this prior to the web MIDI API): https://github.com/kn0ll/midi.io
experimental 3d step sequencer (quantized, naturally): https://github.com/kn0ll/phon2
the issue i had with quantizing captured input is the latency between the device input and the time it's read into the program. this is why i said "naive" quantization. but it works fine for 1/8 steps, and 1/16 steps at most tempos.
MIDI IO where the keyboard is connected to the server is nifty; not what I meant, though. :)
But I can do without that (or only offer MIDI-in support for people who can run a bridge Java applet); still, the thing I keep looking for is reliable timing for on-the-fly audio (constructed MIDI works for me, I can do that!), and responsive changes based on user input.
Put another way; if you had the spare time, could you fix Vexflow playback[1] so it would actually play on tempo, the first time, in more than just Chrome? (Even in Chrome, it's not reliably solid...) Next, what kind of response time can I get when someone clicks on the UI (a keyboard, or whatever)? Is there a way I can play a MIDI note fast enough that it reliably sounds immediate?
I implemented this stuff in Java 11 years ago, mixing audio samples on the fly, not using MIDI, but I'd be happy to use MIDI if it can mean playing multi-voice audio cleanly and w/o loading a library of audio samples; I've spent enough time working with MIDI as well (as part of handling MIDI input).
I didn't try your phon2 yet (should I?), though I notice the latest checkin comment is about battling with audio choppiness. ;)
[1] http://my.vexflow.com/articles/53?source=enabled find "playback"
but at any given point, you know what sample is being output. you also know if MIDI is being captured. isn't quantization just an exercise of mapping the input to a quantized sample? which is just a matter of rounding assuming you know your samplerate.
ie. if there are 1000 samples in a measure (entertain me), and you quantized to 1/4, and you capture MIDI while sample 700 is being output, you just map the note to the 750th sample. what am I missing?
just want to be clear my curiosity is genuine, I don't have a deep understanding in dsp or signal analysis or anything. my only knowledge of this stuff is just barely making it work for me. so I'm wondering what I'm missing :)
phon2 is definitely worth a try but I just realized the demo link wasn't working. if you're familiar with grunt it should be a quick setup though :) I also realize a server component for midi is not what anyone had in mind; but the web midi api wasn't implemented at the time I needed a solution.
No need to get into DSP issues; it's just that playback and input go hand-in-hand.
Think about playing a click track so that someone can enter notes (by clicking on the screen, for a simple example).
If you have varying (audible) latency in your click track, the user can't hear where the beat is (ugh); secondly, even if you capture exactly when they click the screen, your next task is to map that onto when the beat fell. And if you don't know close enough to even quantize reliably, you're stuck.
Next, the latency between "user clicks a note" and "audio plays selected note" needs to be pretty small -- think of the user above playing along with the beat... and so they click the screen, timed exactly when when the sense the next beat will fall. If the actual audio can't be triggered for another 200ms, it just sounds terrible.
The latency I notice in the OP app is particularly bad because it seems to vary a lot -- I can click a key in a very steady rhythm, and it captures a very unsteady beat.
Quantization can't really fix this problem; the delays seem to be uneven enough (and serious enough) that even if it barely managed to figure out "8th notes", mixing in some triplets or grace notes wouldn't go well.
phon2 -- cool, I'll give it a try when I have a bit of free time.
WRT WebMidi -- that's awesome, I hadn't seen the spec appear; I can't rely on it until there's better browser support (it looks like Firefox has only just started initial work on this, for example), but it's certainly also prove another motivator for fixing up audio timing issues all over.
I guess my confusion then lies in the history that I've never had such drastic playback inconsistency in my applications- so midi input synchronization seemed consistent.
I wonder if this has something to do with lack of complexity in my applications. like you suggested I should definitely read up on these playback issues and why and when they're occurring.
Thought it was going to be this (very fun) JACK-based loop-sampler. The name not exactly the same, but it seems close enough to be mildly confusing.
Maybe change the name slightly? (I'm no expert on naming issues; it might just be my lack of coffee)
Thought I'd share my tune with you guys and perhaps the person who made this sees it and finds it funny.
Rather catchy if I may say it myself.
Edit: here's what one of the save links give you: http://superlooper.universlabs.co.uk/OHu1
or another that's a bit more spare: http://superlooper.universlabs.co.uk/4wCk
The slightly-missed timings are a bit hard to listen to, but this is great fun.
(Windows 7, Firefox 31)
The problem is that even if you trigger something precisely with javascript,the way some browsers handle audio make sequencing totally unreliable.
for what it is, i think the usability issues are more severe (no quantization, inability to modify a sequence, no pre-roll or indicator of where in the loop you are recording, can't seem to play over another track without recording).