Assigning certain colors to certain midi values

Hi all,
I have recently discovered nodebox and already love it. I ve been reading a lot here and have tried things out but now I m stuck.
I have downloaded the midi import example and I understand what it does so far.
What I would love to achieve is, to assign certain colors to certain midi values/numbers. So I have made a csv list that contains
Midi number, Note value, Hex Color Number and Color Number. The range here is bigger than the midi numbers in the midi example.
How can I assign the Hex color numbers of my csv list to the midi numbers ?
I was reading what John was writing in this example but could not transfer that into my file:
https://forum.nodebox.net/t/19187551/assign-color-by-lookup

Also is there a way to not only show the midi rectangles with the correct color but also write the values of the csv colum "Color" into them as small text ?
And can I somehow place additional small black rectangles only to certain midi numbers ?
It s a lot, I know :/ Maybe someone can put me to the right direction.
Any tips are welcome....
Thanks a lot in advance.
Tom

Here are the file again..

Hi Tom,

Welcome to the Nodebox community!

Interesting project! There is indeed a way to do everything you asked for. See screenshot and attached demo. The zip file contains your files, the midi.clj code library, and my revised Nodebox program, Coloring Demo.ndbx

You were on the right track with your CSV file. I notice you looked up all the keys in that file and reformed them into a table. There was no need to do that; you can suck the value right from the CSV node.

First, I assume by "Midi number" you mean pitch. The trick to assigning colors based on pitch is to filter your CSV file using the filter node. When you tell it to filter your lookup table where Midi = Pitch, it will fire once for each note and produce one row from your CSV matching each note in the source example file. 319 notes in, 319 rows out.

Once you have those rows you can lookup HexColor, Color, and whatever else you need.

To color the boxes, all you need is the HexColor. One small thing: in order to convert those HexColor strings into colors, you need to add a "#" to the front before feeding them into a color node. I did this using a concatenate node.

Adding the Color numbers is almost as easy. Lookup Color, feed it into an Integer node to remove the unsightly ".00" after each value, and just feed it into a textpath node. You can use a fit_to node to adjust the size to fit each box. This also automatically locates the labels inside the correct box!

Since width is the critical factor in this case, the width of each label will exactly match the width of the box, making it a bit crowded. I added a scale node to give the label some breathing room.

Your final ask was to add a small black box for only certain midi numbers. To demonstrate this technique I looked up your Note values and added that box only for notes containing a sharp (#). A placed the little boxes just below each label and then used a cull node to remove any note that did not include a sharp character. If that's not what you wanted you can just change the test feeding into the cull node.

This should be enough to get you unstuck. You will probably want to fiddle with the settings and maybe add more nodes to handle more general purpose sources with variable note durations, multiple channels, etc.

Let me know if that answers all your questions, and please come back with more. This looks like a fun project!

John

John,

wow ! :D I m just reading through all of this and going to the nodes step by step. It sudeenly makes so much sense. It also shows that using it, you have to get used to thinking differently a bit. I also noticed before that it kind of didn t work connecting the Hex numbers without the # to a color node and though, uh what if I had made a list containing hundreds of numbers, I would have gone through all of them and putting a # back in the list. But this with the concatenate node is super smart :) also the lookup for the notes with a # for an additional element :) This all opens up so many more possibilities to me to try out and maybe use in a different context as well, and raises my learning curve a lot . Thank you very much for taking the time and explaining it. Kind of seems here that you have nodes in your genes :)

best regards
Tom
Gunther

Glad I could be of help. And you're right: you do have to learn to think a bit differently, especially if you're used to coding in traditional languages. I've been at it for years and am still learning.

I look forward to seeing some of what you do with your new found power!

John

I ll be happy to share what I will come up with ! :)
Thanks and happy week ahead.
Tom

Hi again :)
I have been playing around with it a lot. Very cool and great fun.
There is just one thing I noticed that I just cannot figure out or understand.
In the earlier Midi_Color_Test example, all looks logical. Notes of the samle value/pitch number are at the same y position, defined by the pitch lookup -> convert pitch -> make point -> align.
So far so good. But when I load in an other midi file (i.e. the attached one). rectangles with the same note / pitch value are jumping all over the place and arent at the same y position.
Could it have something to do with the make point node and the x and y going in being floating values ?

Best regards
Tom

Hi Tom,

I can't tell exactly what's going on unless you send me a (zipped) copy of your ndbx file. From the screenshots it looks like you modified my Coloring Demo somewhat.

But it doesn't surprise me that the notes are wildly scattered and overlapping. The dimensions and position of each note rectangle are driven by some highly sensitive fudge factors in a simplistic way that makes collisions inevitable. Fractional differences in the pitch values are greatly magnified, but those same values are converted to integers for the labels, so that 112.2 and 112.3 wind up at different Y positions, but both have labels reading 112.

You should be able to see this by simply following the tree of nodes and rendering (double-clicking on) each one:

• Each note rectangle is aligned to the left of an X and the center of a Y
• The X is determined based on the tick value interpolated against the total width
• The Y is determined based on the pitch interpolated against the total height

It can be difficult to follow this for hundreds of notes all at once. So one debugging trick is to insert a slice node at the top so you can trace one note at a time. Insert a slice node just below the midimport node at the top. Set the slice so that start = 0 and size = 1 and feed the output everywhere midimport went. This will draw the first note in isolation. Change the start value to see subsequent notes.

If you can find two notes which you think should have the same Y value but do not, you can isolate each one with a slice and follow the steps of the process until you see where the discrepancy comes in. To find these notes look at the output of the midimport node using the data view. Identify the two notes using the tick and pitch values, and note their index values (the first column). Set the start parameter of your slice node to each index value.

This slicing trick will serve you well in future adventures. If you are still stumped, send me your entire zipped folder, with the ndbx and all input files, and tell me where you think it doesn't make sense.

John

Hi John,
thanks so much again for the quick reply and the awsome hint of bringing in a slice node. Before this I didn t even had an idea what a slice could be used for :)
I have to investigate that further tomorrow. But I already found some misbehaving bits parts. I will now check if it might be caused by my csv note value color list that is not covering the complete possible pitch range.
In the slice node, there is a tick box "invert", what does that mean ? if ticked, it goes from "back to front (end to start)" rather than from "start to end"?

Best regards
Tom

Hi Tom,

If you set the start of a slice node to 0 and the size to 1, it will return the first item of a list.

If you check the invert box, it will return everything EXCEPT the first item.

This turns out to be surprisingly useful. If you feed a list into two slice nodes with identical settings except the invert box, you will divide that list into two parts, A and B. You can then do one thing to A, a different thing to B, and then recombine them.

Another example. Sometimes you want to act on everything except the first x items of a list without knowing for sure how many items are in that list. To extract those items you could set slice start to x and size to 1,000,000 (assuming you were certain the list would always have fewer than a million elements) but this would be kludgy and amateurish. Or you could use a count node to find out how big the list was, and a subtract node to set the size to count - x, but that's cumbersome.

The elegant solution is to set start to 0, size to x, and then check the invert box.

John

John, thats amazing ! :) Thanks a lot for those informations and tips. Makes total sense .
In the meantime I was checking the misbehaviour in my files with the slice node, checked back on the values and numbers and I think I found the mistake. My csv file did not cover the whole midi range, there were midi notes that werent covered in the csv list and that was the point when things started to jump all over the place. :) problem solved, thank you !
Best regards
Tom