Approach to MIDI Graphic Representation?

Nov 11, 2008 at 5:41pm

Approach to MIDI Graphic Representation?

Hello all,

I am a student in an introduction to MaxMSP class and have a question about how to approach doing a graphic MIDI representation of velocity. My classmate and I were assigned a side project to do this and we’re pretty clueless on how to approach this. Any ideas on what is the best way to compile MIDI data and then create a visual representation of velocity over time?

Thanks!

#40776
Nov 11, 2008 at 5:52pm

the jitter tutorials.

On Nov 11, 2008, at 12:41 PM, Galen wrote:

>
> Hello all,
>
> I am a student in an introduction to MaxMSP class and have a
> question about how to approach doing a graphic MIDI representation
> of velocity. My classmate and I were assigned a side project to do
> this and we’re pretty clueless on how to approach this. Any ideas
> on what is the best way to compile MIDI data and then create a
> visual representation of velocity over time?
>
> Thanks!

#144602
Nov 11, 2008 at 6:01pm

Quote: blokeyhighlander wrote on Tue, 11 November 2008 09:41
—————————————————-
>
Any ideas on what is the best way to compile MIDI data and then create a visual representation of velocity over time?
>

Velocity is a simple numerical value, so there are a lot of straightforward visual representation possibilities. Position (higher on y-axis means louder), size (a larger shape means louder), or color (maybe red means loud & blue means soft) all seem like good options.

I’d stick with the standard x-axis as time going from left to right.

You can play back a midi file and draw into an lcd object to achieve something like this.

Depending on how serious you want to take this project, you may want to look into the work of Edward Tufte for more ideas on visual representations of quantified data.

#144603
Nov 11, 2008 at 6:03pm

#144604
Nov 11, 2008 at 6:05pm

Quote: Adam Murray wrote on Tue, 11 November 2008 11:01
—————————————————-
> Quote: blokeyhighlander wrote on Tue, 11 November 2008 09:41
> —————————————————-
> >
> Any ideas on what is the best way to compile MIDI data and then create a visual representation of velocity over time?
> >
>
> Velocity is a simple numerical value, so there are a lot of straightforward visual representation possibilities. Position (higher on y-axis means louder), size (a larger shape means louder), or color (maybe red means loud & blue means soft) all seem like good options.
>
> I’d stick with the standard x-axis as time going from left to right.
>
> You can play back a midi file and draw into an lcd object to achieve something like this.
>
> Depending on how serious you want to take this project, you may want to look into the work of Edward Tufte for more ideas on visual representations of quantified data.
—————————————————-

Thanks for the reply,

Yes, I just want to do a simple representation using the delta time from borax on the x-axis and the velocity on the y-axis. We’re just Max MSP newbies here so I do not know how to capture the data and then turn it in to a graph. The goal is to take a recorded MIDI file (have that done), and during playback have it output the elements stated from borax in to a list, and then draw that. I just don’t know how to do this from the coding standpoint.

#144605
Nov 11, 2008 at 6:08pm

So basically, how do I:

Put delta time and velocity in to a stored list such as coll;
Then take that data and draw a graph.

#144606
Nov 11, 2008 at 6:22pm

Sorry for the barrage of posts – we figured out how to capture the information correctly using capture (go figure) – we just aren’t sure how to make it a graph.

#144607
Nov 11, 2008 at 6:23pm

To draw time properly, you’ll probably need absolute time, not delta time. Take a look at [accum] to sum up all your delta times to get the current absolute time.

Once the data is in a [coll] use a “dump” message to get it out and draw something using [lcd] or jitter objects.

[scale] would be helpful converting the raw numbers to x & y coordinates so you can draw properly.

You’ll need to spend time with the help files and tutorials if you don’t know how to use these objects. If I say much more I am pretty much doing your project for you. But I know it’s tough when you don’t even know what objects you need to use.

#144608
Nov 11, 2008 at 6:29pm

You might consider using the multislider. If you give it about 1000 sliders, it will give you a decent horizontal resolution, and it will be a bit simpler than using the LCD object, since you can just give it a message like “set 14 127″ to set one of the sliders. Whichever method you use, one of the main issues is to “thin out” the data. For instance, if there are three notes played simultaneously, are the velocities added, averaged, etc.? Each slider will represent a certain time span, so you will need to figure that out, combine all of the events within that time span, and then scale the time values so that each one corresponds with one of the sliders (or whatever you’re using).

I would also say that this assignment seems fairly advanced for an intro to Max course. There probably wouldn’t be any shame in asking the professor for help–he/she might be able to point you to some earlier assignments or lectures that might be helpful.

#144609
Nov 11, 2008 at 6:30pm

Quote: Adam Murray wrote on Tue, 11 November 2008 11:23
—————————————————-
> To draw time properly, you’ll probably need absolute time, not delta time. Take a look at [accum] to sum up all your delta times to get the current absolute time.
>
> Once the data is in a [coll] use a “dump” message to get it out and draw something using [lcd] or jitter objects.
>
> [scale] would be helpful converting the raw numbers to x & y coordinates so you can draw properly.
>
> You’ll need to spend time with the help files and tutorials if you don’t know how to use these objects. If I say much more I am pretty much doing your project for you. But I know it’s tough when you don’t even know what objects you need to use.
—————————————————-

Yea, I just did a simple + object adding the previous delta time to the total time. I’ll take a look at the other things.

Thanks!

#144610
Nov 11, 2008 at 6:33pm

Quote: Stephen Lee wrote on Tue, 11 November 2008 10:29
—————————————————-
> You might consider using the multislider. If you give it about 1000 sliders, it will give you a decent horizontal resolution, and it will be a bit simpler than using the LCD object, since you can just give it a message like “set 14 127″ to set one of the sliders. Whichever method you use, one of the main issues is to “thin out” the data. For instance, if there are three notes played simultaneously, are the velocities added, averaged, etc.? Each slider will represent a certain time span, so you will need to figure that out, combine all of the events within that time span, and then scale the time values so that each one corresponds with one of the sliders (or whatever you’re using).
>

That’s an interesting idea. I will agree it’s easier to work with multislider, but if you’re just drawing into a blank canvas like [lcd] then you don’t need to worry about thinning out the data. Just keep drawing over top of what’s already there. It might not give the best results, but I think the “data thinning” logic could get really complicated so best to avoid it for a first pass. Just my opinion of course.

#144611
Nov 11, 2008 at 6:38pm

Appreciate the input – basically the idea was to create two separate collectives with one taking in the total time and the other taking the velocity. Via stripnote, we are able to have each velocity have a total time value that correlates with it. There would then be the same number of items in each list each correlating with the parallel value.

Ex.

Velocity: 67 34 66 90 130
Total Time: 300 650 723 903 460

So with everything correlating, we thought we would be able to take the nth item of both lists and output it to some object that takes x,y arguments – we’re just figuring that out still.

#144612
Nov 11, 2008 at 6:43pm

Why not just use one coll and store the time values as the index, and velocity values as the data?

#144613

You must be logged in to reply to this topic.