Help with midi chord and Coll system
Hi,
I am building a patch that when ever someone is hover with his mouse above a certain message box it will generate a midi chord based on an initial choose of scale, a root note and octave range.
area marked "1" is the hover message boxes that should send a message in order to generate a midi chord
when I change the live.dial name "KEY" in area "3" the notes of the chords of the scale are shifting accordingly which is seems to work just fine!
area marked "2" sending the chord name into a text box which is also working fine.
what I'm trying to do:
to make a system that changes all of the message boxes according to a specific key that is choose in area "3" and according to the type of scale choose in the live.tab object in the middle-left of the patch.
How can I do so?
here is my patch I got so far. Thanks!
With all the send/receive links you have in there it's a bit difficult to follow the logic but I get the idea of it.
My though was to create a coll with 24 entries with all the preferred note names that cover two octaves. You could dump the output of a selected coll from the left-centre (notes_maj, notes_min, notes_min_harmonic) and offset the values with the output from the Key control (add the values together) and use this to direct the note names coll to feed out the 8 note names for each scale. You can then pass these through a cycle 8 object to direct each to the respective right-hand input of each message object in section 1 to rename it.
Does that make any sense?
I've created a small patch with my suggestion for you to play with:
Or this one which also uses the toggle to select the correct scale coll:
This is great! dump was the answer. many thanks
edit: while working fine - how can I add for each degree of the scale if it is minor or diminished? similar to the system I made in area "2" ?
I found a bug in the first system you shared. the first time I choose to "KEY" to be C it display the degrees has is should: C D E F G A B C .
When I change the key up by one and then move it back by one to C it display: C# D E F G A B C
why is that bug?
edit: I solved it by changing the "delay 2" object to "t i i" object.
The delay 2 was in there just to make sure that the loop executed in the correct order. As I presume you know, Max does not always execute steps in the order you might have planned and things can go wrong by simply moving one object in the sandbox relative to another! The Max scheduler will always execute from the bottom right to the top left given half a chance- quite the opposite to how we lay things out! Any sort of delay or trigger will do the trick - maybe delay 2 wasn't quite enough on your system?
I presume that you also saw the second patch I uploaded that includes the scales dumped via a gate controlled with your scales tab?
You also mentioned specific keys like Cbmin but you're getting quite complicated with that. You'd have to create a coll that stores your preferred note names for every key that you use and do the output from that - if each key was defined on a separate line in the coll, you could reference each line of note names with an index rather that doing a dump. How you'd organise it depends on how many different scales you would expect to see in each case - Maj, min, min-harmonic, etc.
I presume that you also saw the second patch I uploaded that includes the scales dumped via a gate controlled with your scales tab?
I did saw it. Thanks. I changed my Coll system to use multiple txt files instead of multiple Coll object.
You also mentioned specific keys like Cbmin but you're getting quite complicated with that. You'd have to create a coll that stores your preferred note names for every key that you use and do the output from that - if each key was defined on a separate line in the coll, you could reference each line of note names with an index rather that doing a dump. How you'd organise it depends on how many different scales you would expect to see in each case - Maj, min, min-harmonic, etc.
This idea should work, but If I'm gonna have line 12 scales with the option to shift each scales by 12 different notes it will become pretty complicated data arrangement. I will try to figure it out. You gave me a great place to start from
Is there a better way for processing the chords in area "3" then using vexpr objects?
Why change it if it works? I can't think of an obvious improvement but I'd have to really study it to work it out. It's like all things - there are many ways to achieve the same end result and part of the fun is exploring the alternatives.
My gigantic, current (and first ever Max) project has been a pretty steep learning curve! It was based on a considerably smaller project that had been started by somebody else who had some "interesting" ways of doing things. If you analysed how it all works, you could see how the coding style has changed as I have developed more and more components. I've now started to go back through the earlier modules and make improvements based on what I have learnt along the way. Having learnt my programming skills in very rigid languages like machine code, Fortran and Pascal, it has taken me a while to adapt to the huge flexibility in Max.
It's taken me a year to get my project to a "finished state" but I still keep tweaking around the edges and thinking of additional functions to add. The next big leap will be dumping the bit of software that sits between my project and my X-Mixer and converting all the MIDI commands to OSC!
Why change it if it works? I can't think of an obvious improvement but I'd have to really study it to work it out. It's like all things - there are many ways to achieve the same end result and part of the fun is exploring the alternatives.
Why change if it works? This sentense say it all. (thinking on it while typing I can think of a reason to change something even if it is working. For example if you want to make it more flexible for future additions)
Thanks for your insight though!