31–37 of 37 posts
I really liked to play with this. Being able to create "music" without knowing anything about it. 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. http://superlooper.universlabs.co.uk/33un
I really liked to play with this. Being able to create "music" without knowing anything about it. 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. http://superlooper.universlabs.co.uk/33un
Couldn't help but to make another one... http://superlooper.universlabs.co.uk/tFMe
Earlier quoted context omitted.
links or it didn't happen. ;)
unfortunately i don't have the code for the step sequencer that used both implementations. but i can share some of the libraries i've released that stemmed from it: 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)…
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"
Earlier quoted context omitted.
unfortunately i don't have the code for the step sequencer that used both implementations. but i can share some of the libraries i've released that stemmed from it: 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)…
Ha, I post a cynical complaint like this once every few months, hoping someone will prove me wrong one of these days. 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…
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.
I really liked to play with this. Being able to create "music" without knowing anything about it. 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. http://superlooper.universlabs.co.uk/33un
Earlier quoted context omitted.
Ha, I post a cynical complaint like this once every few months, hoping someone will prove me wrong one of these days. 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…
this is my point though. i recognize there are latency and timing issues but they seem related to 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),…
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.
Earlier quoted context omitted.
this is my point though. i recognize there are latency and timing issues but they seem related to 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),…
> i recognize there are latency and timing issues but they seem related to playback. 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 e…
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.