Midiroll

Jay · 14 May 2010

Woot! Thats cool! I love that idea! Quite light on my machine even playing lots of fast notes!

It kinda reminds me of a piano game i saw on youtube a while ago (can't remember what it was called) except the piano was below and the note markers came down towards the piano and lit up the keys 🙂

Best Regards

EDIT: There it is....

philter5 · 14 May 2010

😍 😍 😍 thank you! i have to try this out right now. can´t wait

mwvdlee · 14 May 2010

Jay wrote: EDIT: There it is....

Teehee! That's like "Rock Band" for people who can actually play a real piano 🙂 I'm guessing I'd fail at level 1 🙁

FWIW I've been improving the code a bit but nothing major yet. I'm mostly trying to get the data structure and memory module faster and getting rid of the "midnight" case, which sounds easier than it is. I'd love to see what other people can come up with in the visualisation bit.

Jay · 15 May 2010

Oh goody goody! i found out what it is called - "Synthesia". Best bit is it's Free!

here a the link http://www.synthesiagame.com/getTheGame.aspx

gonna give this a whirl.

EDIT: As to your osm, yesterday i got it working for all 88 notes on my main keyboard then got it working in a downward motion like that game and i left off trying to get the little note indicators to fall in line with the notes on Oddson's groovy keyboard GUI didnt manage it though!

How do you change the width of each note slice? i tried changing the loop step size!. I am wondering if we could get it to show the lengh of notes just like that game 🙂

Best regards

mwvdlee · 15 May 2010

Here's another version, which should perform better.

* The records in memory are aligned now, so it's easier to extract. Since the schematic decodes much more often than it encodes, this should improve performance. * It only periodically removes older entries from memory. The removal time can be set and the ideal time is probably a trade-off between size of array to loop and how often to loop. * When memory size is zero, most things get shut down to increase performance when inactive. * Mono code timer practically eliminates the "midnight" issue and should be faster. * some other things I've forgotten.

Sadly enough, accurately and consistently measuring performance on this one is proving to be difficult.

aliasant · 15 May 2010

mwvdlee wrote: Here's another version, which should perform better.

* The records in memory are aligned now, so it's easier to extract. Since the schematic decodes much more often than it encodes, this should improve performance. * It only periodically removes older entries from memory. The removal time can be set and the ideal time is probably a trade-off between size of array to loop and how often to loop. * When memory size is zero, most things get shut down to increase performance when inactive. * Mono code timer practically eliminates the "midnight" issue and should be faster. * some other things I've forgotten.

Sadly enough, accurately and consistently measuring performance on this one is proving to be difficult.

This is a funny little gadget for sure 🙂 Nice work. Was thinking about the notes being drawn the "wrong" way. Lower notes are drawn higher up and vv. Not sure if there is a right and wrong here but compared to other keyboard views I think it is. Was trying ( for 3 minutes) to reverse this but I havnt figured that out yet. I have another list that had the same issue and I did find a way to reverse it but I think that list was limited to a fixed array size but I think this could be done simple enough by taking the list and reverse it before sending it to the decoder but it has to be done often and might slow it down.

An other way could maybe be to rotate/flip the drawn area instead?

I was trying to reverse the V loop but that didnt quite work... I have spent a lot more time writing this the actually fiddling with the osm.. Ill try later on today.

mwvdlee · 15 May 2010

aliasant wrote: An other way could maybe be to rotate/flip the drawn area instead?

That's the way you should do it. There is no significant order in the list, so reversing it will do nothing. To flip vertically, do some math on the Pitch coming out of the decoder. To flip horizontally, work with Time signature from the decoder after it's been subtracted from the current time signature. I just made what was quickest to make, so therefore both are reversed from what you'd normally expect.

aliasant · 15 May 2010

mwvdlee wrote: aliasant wrote: An other way could maybe be to rotate/flip the drawn area instead?

That's the way you should do it. There is no significant order in the list, so reversing it will do nothing. To flip vertically, do some math on the Pitch coming out of the decoder. To flip horizontally, work with Time signature from the decoder after it's been subtracted from the current time signature. I just made what was quickest to make, so therefore both are reversed from what you'd normally expect.

Thanx. Ill see what I can do later on today 🙂

mwvdlee · 15 May 2010

Jay wrote: How do you change the width of each note slice? i tried changing the loop step size!. I am wondering if we could get it to show the lengh of notes just like that game 🙂

Do not change the loop size. The loop iterates over the amount of "records" in the array that is passed between the memory and viz modules, changing it means skipping or doubling notes.

Currently, the array is basically a list of records made up of a time signature (relative, not absolute) and the pitch and velocity as provided to the memory module. The order of the list is insignificant

If you wanted to visualize the length of notes, that would mean we'd also needed to have the length in the array somehow. I don't think it'd be efficient in the current design.