Chord/Scale-Tool

MichaelBenjamin · 22 Apr 2010

nice tool, but it doesnt take very long to load, about ~3 sec which i think is fine. what you could do about the other scales is simply add +1 to every display data for a halftone step once, so you can basically keep the osm like it is and only need to add the conversion integer 0-11 to c.. c#..d.. and key display shift once.

oddson · 24 Apr 2010

I was expecting much worse for a mess inside but I think it's actually very tidy except that the level of complexity is too great because of a dubious design choice made early on.

I don't think that the path you've taken is worth following all the way there... each new note will take nearly as long as the first to set up and you're not capitalizing on what's the same from one to the next. (It looks like you have to build each chord manually so that its components line up and that its optional notes show properly!).

And when you go to implement the scale feature it will only get worse.

If I were starting from scratch I would start with how to record the offset patterns for each note and figure out a way to record that data so the schematic can do the work for you in terms of giving the user the visual response you're looking for.

Since you need only store integers for note offsets you could use a fractional value to represent that a note is optional.

So the name and the sequence of intervals as well as whether any note is optional could be stored as a string:

13+11,0,4.1,7.1,10,14.1,18,21

Then you could parse through each string (when it was selected and add these offsets to the root position on the keyboard display. Each key on the keyboard would need it's own 'play' marker that is turned on when the note is to be played (rather than moving them around or having each chord definition having it's own set of markers).

The intervals and half-steps could be calculated from the offsets but you'd need to do something else for AKA strings and, as yours have commas, it may mean something complex unless the AKAs are stored in a separate data structure.

Or, you could build something like an formal data structure so that formalized delimiters provide the data and the parser components can be used to extract the data from a text-based master file.

E.g.

//Chord; Name:13+11; Offsets:0,4,7,10,14,18,21; Optional:0,1,1,0,1,0,0; AKA:<*>13 augmented 11;

//Scale; Name:Major; Offsets:0,2,4,5,7,9,11; Optional:0,0,0,0,0,0,0; AKA:Diatonic,<*> Ionian;

Once this part was done (the work would be about 50/50 between building the data definition file and building the parser module to turn it into useful data) the rest would be relatively easy. If you do the the data definition file I will help you get a parser working and help you avoid some pitfalls for the rest of they way.

Are you interested in my assistance to complete your project in this manner?

By-the-way... going this route would mean you could put together a Guitar version quite simply as a next project.

P.S - if you are interested now's the time to start thinking about features that involved chord or scale specific data storage to avoid having to rebuild large part of things later on before you're stuck with new design limitations.

oddson · 24 Apr 2010

The 'Tunings' section of a guitar tuner project I was working on recently shows the simple parser concept in action.

Here a guitar tuning is defined by a name and the MIDI note values each string should be tuned to... This allows the project to be generalized for non-standard tunings.

infuzion · 24 Apr 2010

I would use a float or string array, each row would be 1 note, & the value would be = root, etc. At end of updating the array, an "activate trigger" would make each note to re-load their row from the array, update values, send MIDI (if configured), & update graphic (that is located inside the key module, not the chord module). The row value would be fixed for each note, so pulling it out of the array would take only an Array Get At. Just a thought 🙂

oddson · 24 Apr 2010

infuzion wrote: I would use a float or string array, each row would be 1 note, & the value would be = root, etc. At end of updating the array, an "activate trigger" would make each note to re-load their row from the array, update values, send MIDI (if configured), & update graphic (that is located inside the key module, not the chord module). The row value would be fixed for each note, so pulling it out of the array would take only an Array Get At. Just a thought 🙂

That's roughly the same idea but you have to keep track of the string data separately.

I think a more structured approach would pay off when the number of chords and scales gets large as adding and altering would be much easier if the underlying data is fully structured in a human friendly way. Once it's loaded and parsed it would be stored in float or integer arrays as offsets.

Either way I think infuzion and I would agree that manually setting markers for each chord is too hard to maintain and expand on... some type of formalized data storage with note markers on each key triggered by program logic is the way to go.

infuzion · 24 Apr 2010

oddson wrote: I think a more structured approach would pay off when the number of chords and scales gets large as adding and altering would be much easier if the underlying data is fully structured in a human friendly way. Once it's loaded and parsed it would be stored in float or integer arrays as offsets.

I see your point. But either way, one must use a translator from typical chord notation (Cm etc) to something the program uses. None of the users will care how the VST works inside. My first programming experiences were with arrays & spreadsheets, so that's how I think. People who first program with HTML like XML etc for storage. I'll vote for the fastest way, either way, since live performing VST speed > code readablity.

Programming the imputing the chords should be done once an text archive of chords is found. The actual storage & retrieval should be done via the fastest (CPU) method. So perhaps both approaches may be used, one at first, other at run-time?

oddson · 24 Apr 2010

orangeblue wrote: at the moment i have made only C and it take some time to load... so i wanted to see how long it would take when it is complete.... i copy C to all other and after 15min it was ready and up

Surely you don't mean that in 15 minutes you had a version with the other eleven note values running and displaying properly! You mean displaying the incorrect C-natural versions in their place right?

I can't imagine how you even did one version as I can't tell how you would have lined up the markers over the keyboard without the visual feedback of the keyboard showing below the markers in the GUI panels.

Another issue is enharmonic spellings for black-note roots... I suggest it defaults to flat names on first click with the flat note highlighted on the button in some way and then the second click would switch to the sharp version. But there would have to be nearly complete recalculation of the text strings.

I know my approach may sound complicated but its because the complexity is consolidated in the data storage and retrieval to minimize the complexity in the GUI -- I'm pretty sure it would be worth it in the long run.

infuzion · 24 Apr 2010

oddson wrote: I know my approach may sound complicated but its because the complexity is consolidated in the data storage and retrieval to minimize the complexity in the GUI -- I'm pretty sure it would be worth it in the long run.

I agree 🙂

orangeblue · 24 Apr 2010

oddson wrote: orangeblue wrote: at the moment i have made only C and it take some time to load... so i wanted to see how long it would take when it is complete.... i copy C to all other and after 15min it was ready and up

Surely you don't mean that in 15 minutes you had a version with the other eleven note values running and displaying properly! You mean displaying the incorrect C-natural versions in their place right?

I can't imagine how you even did one version as I can't tell how you would have lined up the markers over the keyboard without the visual feedback of the keyboard showing below the markers in the GUI panels.

Another issue is enharmonic spellings for black-note roots... I suggest it defaults to flat names on first click with the flat note highlighted on the button in some way and then the second click would switch to the sharp version. But there would have to be nearly complete recalculation of the text strings.

I know my approach may sound complicated but its because the complexity is consolidated in the data storage and retrieval to minimize the complexity in the GUI -- I'm pretty sure it would be worth it in the long run.

thank you for all the suggestions. yes i only wanted to know how long it would take to load when all 12 notes would be all correct. this thing is nearly 1 year on my hd but i have not had the energy/time since i am on mac now. i also forgot already the most what i have learned about synthmaker so when i read what you wrote i understand only half of it. my initial idea was to make a education/training tool for my son with he can practice his skills. i also like the idea to have it as a vst inside your daw for quick reference. i see not many plugins like this at the moment . sorry for english

now i go study your tuner osm. thank you.

oddson · 24 Apr 2010

Dont' waste your time with the rest of the file... just the parser module that's there when you open it.

oddson · 25 Apr 2010

So here's something for the other end of the work...

Once you have a system for storing and retrieving the chord/scale data you'll need to be able to mark the notes based on integer arrays.

This file is a stripped down version of yours with an altered keyboard module that contains markers on each note.

A wireless integer array named "Marked" is beamed down into the keyboard to tell it which notes should be marked.

It's still a little rough and it can/will be made better and more flexible for altering its visual appearance but I wanted you to have a peak in its current state to see how the other side of this project should come together.

Then in between the data storage and retrieval and the display is a bit of simple logic...

oddson · 25 Apr 2010

Here's my proposed replacement for the chord selectors:

chained radio selector.osm (Link removed - crashes ... see MB's version below.)

It generates an index value to look up the offsets etc. for whichever chord is selected. You don't need 12 of these, just 1 and it's possible the scales could share the buttons or at least you'd be able to quickly build a selector for them too.

MichaelBenjamin · 25 Apr 2010

oddson wrote: Here's my proposed replacement for the chord selectors:

this instantly crashes sm when i click on an already selected button..?

MichaelBenjamin · 25 Apr 2010

an int sample&hold before the int switch fixes it. i wonder if thats kind of a feedback loop from the int switch back to the int equal that makes this crash. or something with the changed triggers in the later betas. i use the most recent 1.1.7 btw.

MichaelBenjamin · 25 Apr 2010

heres the non crashing version

oddson · 25 Apr 2010

Thanks Mike...

Have you determined if the the trigger order important here? Are both S&H needed?

There might be a better way to avoid that crash as it still seems to me the feedback loop is open.

But this will do until/unless I figure out a better way to ensure the loop stays closed.

oddson · 25 Apr 2010

This is a plan schematic for the full project as I envision it.

The modules are as as follows:

Data Retrieval - Reads a text file that allows you to maintain the projects musical data separate from the SynthMaker project. It would likely just be a Text Load primitive and a File Dialog but may replace white-space delimiters with characters that the Parser component can work with. It's marked 'Purgeable' because it would not have to remain part of the exe/VST file as the data would be stored elsewhere in array form. (<1hr?)

Parser - Takes the (treated) text string and turns it into array data. It's also purgeable as I figure the data would be stored by the receiving modules in S&H array primitives. If the text is treated to add usable delimiters from the Date Retrieval module then it could likely be implemented with SynthMaker's Parser components and should be fairly easy to complete (if the data is well organized). It's output consists of: *Names array which includes all the chord and scale names (it may need to include a 'break' line to indicate where one ends and the next starts or something similar) *Aliases array which includes the text stings for alias including some root place holder so the root note string can be inserted in strings like C#7. *Offset Strings - an array of text strings, each of which defines the offsets for a given chord or scale *Offset Type Strings - an array of text strings, each of which indicates information about function of each note offset in the chord or scale (this could be as simple as indicating the optional elements of chords but it could also store scale degrees or some other info). Optional members could be -1 values. (4-5 hours)

Names - A simple module the beams wireless string arrays with the names of chords and scales for the user interface on the scale and chord selector module. (<30 minutes once you figure how to split Chords from Scales)

Chord/Scale Selector - GUI element to allow user to select chord or scale type. Output is an index for the scale or chord and a boolean for which type (True=Scale?). (I'm assuming the scale indexes would start after the uppermost chord index so there's no need for two index lists.) This one is pretty simple now that I have the selector index thing settle from the above post. (Mostly done <1 hour -left -- need to know how long scale names can be and how many you're expecting to have)

Root Selector - GUI element that lets you select the root note and whether to use the sharp or flat spellings for black-note roots. Output is an index from 0-11 with C=0 and B=11 and a boolean where True=Sharp spellings are used. The only tricky part to this is the sharp indicator and the visual feedback for the user but I'm assuming the chord selector work above could be altered to handle this without too much work. (1-2 hours but could be more if there's a problem with the sharp spellings selectors)

Name String - Trivial module that extracts the short name string and adds the root note for the GUI display. (<30 min)

Alias String - Fairly trivial module that builds the alias string adding the root where needed. (<1hr)

Display Strings - A module that builds the other display strings. This one would have some slightly tricky bits to it and can't be done until the 'Offset Type' issue for the data files is settled. (1-2 hours?)

Offset/Type info - This is a big one... it has to build integer arrays from the string data for both the offsets and the coding info for whether the note is optional or any other special info that we want to display to the user (scale degree?). (4-5 hours?)

Notes - This is a crucial component but should be too hard to make. It builds the integer array that feeds the keyboard map. (1-2 hours)

Display - The GUI... it's mostly done now or is handle one of the to UI modules above (blue). (Mostly done now... but better give a few hours, 3-4, to work out some of the finer points)

Then there's the work of making the data file... I'm thinking something like this:

Which could be exported as a tab/return file and then read by the retrieval module.

This is a major part of the work and getting it right is crucial (although mistakes could be easily fixed).

@ orangeblue - are you in, at least for the data file?

@ everyone else... do you wanna help or do you have any better ideas?

The 'offset coding' issue (which allows for marking optional notes and possibilities for formating scale degree markers etc.) would likely benefit from some comments even if you're not interested in doing any of the build.

MichaelBenjamin · 26 Apr 2010

oddson wrote: Have you determined if the the trigger order important here? Are both S&H needed?

i dont know if both are needed, but i had to reconnect the whole thing to first s&h the int and then the rest to make it work. i was quite surprised that it worked since i was not sure at first and also i am not so good with the green.

btw did it crash for you too? maybe this might lead to some clearance of the latest trigger weirdness issue that came up some days ago.

oddson · 26 Apr 2010

MichaelBenjamin wrote: oddson wrote: Have you determined if the ... trigger order important here? Are both S&H needed?

i dont know if both are needed, but i had to reconnect the whole thing to first s&h the int and then the rest to make it work. i was quite surprised that it worked since i was not sure at first and also i am not so good with the green.

btw did it crash for you too? maybe this might lead to some clearance of the latest trigger weirdness issue that came up some days ago.

I had a crash while building it (lost everything because I've turned off the auto-save feature recently). I guess when I rebuilt it I never tried to click on the already selected button. It kinda makes sense that it forms an open feedback loop at that point though I'm not sure why a S&H would stop it since it's triggered by the same input but it does seem to work.

I need to think the trigger path through carefully -- it needs the feedback to clear the previously selected button but it needs to not form an infinite loop when the feedback value is the same as the current button ID.

I don't think it's related to the 'trigger weirdness' issue but it's certainly an example of the feedback detection not working (although the fact that the feedback is conditional means that may be unavoidable) and of the crash handler not handling.

Thanks again.

trogluddite · 26 Apr 2010

Had similar problems (wuthout crashes thankfully) with this kind of feedback - it seems that some triggers get followed all the way around the loop once initiated, while side branches that seem like they ought to be changing the 'decision making' comparisons etc. kind of get put on hold. Anyway, I really liked that modular way of doing selectors (a cool toolbox item I think), and came up with this - it looks like it has the same sort of feedback structure, but if you look carefully there's no real feedback happening - the sequence starts at the first 'Switch ID' input and ends at the last on/off display, so there's never a complete loop. The little 'get' module simple locks any non-zero value arriving at its input.

orangeblue · 26 Apr 2010

@ orangeblue - are you in, at least for the data file?

@ everyone else... do you wanna help or do you have any better ideas?

----------------------------------------------------------------------------------

hi oddson,

you put so much time and power in it... i will help where i can.

bye.

infuzion · 26 Apr 2010

oddson wrote: Data Retrieval - Reads a text file that allows you to maintain the projects musical data separate from the SynthMaker project. Parser - Takes the (treated) text string and turns it into array data.

MSME has one as "Shape", with Copy/Paste (internal to VST/EXE, not system copy/paste) in the same module. Will need hacking, but a great starting point

Names - A simple module the beams wireless string arrays with the names of chords and scales for the user interface on the scale and chord selector module. Root Selector - GUI element that lets you select the root note and whether to use the sharp or flat spellings for black-note roots.

Not the chord names yet, but here is a note-text_octive to number module that jorge, unkargherth, & I worked on years ago. Int2NoteText uses a Selector to choose the sharp or flat spelling (white keys are listed twice, so the listing is C,C,C#,Db,etc). This was before arrays were available IIRC; so best to put this in an array, but you can check out the logic & my nifty #/b button. 🙂 Please keep full credits intact if using as is or attributing.

Notes - This is a crucial component but should be too hard to make. It builds the integer array that feeds the keyboard map.

I'm wondering if each Key module should just get the full array, & get a trigger to process & display it's array item? I would imagine it would only take a wireless-trigger + Int Array Get At, since I'm assuming the index=note number? Might seem like alot of CPU since every key would be reading the same array for each key, but looping an array & sending the data per row isn't that cheap either...

I've always wanted to do a keyboard training tool, & didn't really know how to approach it well until I was working on the MSME, but I'm still stuck on that project, so I have only a little time to spare. I still believe that all internal workings should be 100% arrays, but loading, saving, & hand-entering could be done via text.

oddson · 26 Apr 2010

infuzion wrote: ...I'm wondering if each Key module should just get the full array, & get a trigger to process & display it's array item? I would imagine it would only take a wireless-trigger + Int Array Get At, since I'm assuming the index=note number? Might seem like alot of CPU since every key would be reading the same array for each key, but looping an array & sending the data per row isn't that cheap either...

I've always wanted to do a keyboard training tool, & didn't really know how to approach it well until I was working on the MSME, but I'm still stuck on that project, so I have only a little time to spare. I still believe that all internal workings should be 100% arrays, but loading, saving, & hand-entering could be done via text.

I entertained leaving all offset data as a single array but here's why I'm leaning away from that idea.

Triads have three notes, some 13th chords have up to seven, scales could have 10 (minor melodic including octave) or more (chromatic? although I don't know why you'd want to show that one).

So you'd be stuck either setting the max number and using placeholders for empty items (and there'd be a lot of empty ones) or recording how many items there are for each in yet another array.

The placeholder version wouldn't be too bad but you'd have to be sure to get the right maximum. The count version would be too complex.

Looping through the strings will only take a tiny fraction of a second to build the offset arrays (the loops would only be 3 to 10 steps and average 4 or 5 for chords and 8 for scales). Given this thing is not a performance tool there's really no risk of the delay causing any major problem (just make sure the screen isn't updating while the array gets built).

I do want to thank you for making me think this through though as the plan as outlined above would have two array loop builds but now I see you'd only want one. So the loop that extracts the offset array data needs to build both the display strings and the note array.

I will keep an open mind about the stringless offset data version and you may win me over yet.

oddson · 27 Apr 2010

Here's a root note selector (complete with enharmonic spelling feature for black notes). Rather than use a boolean to flag 'sharp' spellings I've got it calculating the root spelling since it's used in the display anyway.

The black notes turn 'on' in flat mode and a second click shows them in sharp.

infuzion · 27 Apr 2010

Thanks for the solid demo idea oddson! However, the logic included just to do a simple data-flow job is way way overkill. orangeblue had the button-data idea correct; you only need Switches for the data flow. The turn-off system took some thought but I remembered some trigger order miracle Malc showed me years ago. I provided a quick & flexible example. I've made some of the variable (text & number) names vague to promote recycling.

oddson wrote: The black notes turn 'on' in flat mode and a second click shows them in sharp.

At first I like the idea, but it would require an instruction manual to do this, & I think a program directed at first time learners should be direction-proof. I demonstrated one idea, to have 2 switches, one for # & another for b. Or one can have a master-swtich to toggle # or b mode for all black keys.

I also did some reduction to help me read the OSM better/faster, help save the world from global warming due to smaller file size, & to drive others crazy 😉

attic · 28 Apr 2010

Given this thing is not a performance tool there's really no risk of the delay causing any major problem

This looks like a great project! I was curious about the performance tool statement as some of the things in this project would be great in a performance tool project. How much of a delay do expect could happen?

infuzion · 28 Apr 2010

attic wrote: This looks like a great project! I was curious about the performance tool statement as some of the things in this project would be great in a performance tool project. How much of a delay do expect could happen?

Depends how much $$ you want to cough up to us! 😉

attic · 28 Apr 2010

Depends how much $$ you want to cough up to us!

Damn infuzion are you a car salesman in your off hours. He says show me the money. Yeah I hear you, its a lot of work. I'm broke so my vote is keep the delay. You guys are a tough crowd around here, they think since I'm from San Fransisco that I must be smoking something green and then I must at least have some green as in cough up the ducket's. I don't suppose changing my profile to say suburb of Sf would make any difference. We might as well get the rest of the cliches out of the way ... I'm married to a lady ... as in a girl. lol 😉 😀

oddson · 28 Apr 2010

attic wrote: Given this thing is not a performance tool there's really no risk of the delay causing any major problem

This looks like a great project! I was curious about the performance tool statement as some of the things in this project would be great in a performance tool project. How much of a delay do expect could happen?

I suspect there would be little delay from looping 4-10 data points from a string... but if it did cause a significant delay you could always implement infuzion's suggestion of a single integer array version...

My guess is it's not needed as the amount of time is likely below your threshold of perception. Then the real problem is how to use the data with SynthMaker's timing limitations.

attic · 28 Apr 2010

Thanks Oddson 🙂

infuzion · 28 Apr 2010

attic wrote: Depends how much $$ you want to cough up to us!

Damn infuzion are you a car salesman in your off hours. He says show me the money. Yeah I hear you, its a lot of work. I'm broke so my vote is keep the delay. You guys are a tough crowd around here, they think since I'm from San Fransisco that I must be smoking something green and then I must at least have some green as in cough up the ducket's.

Look at it this way: 1) I work 35-50 hours/week (at least Denver travel time is good compared to SF) 2) I'm working on the MSME which has taken 25 hours this month, & consulting with McBarGig to help out with an upcoming update that is likely to get 100,000+ downloads. 3) I'm trying to work on making more DJ mixes & tracks; BeatPort just happens to be within a bike ride of me & I know some people who work/used to work there. 4) I'm involved with the art-movie scene here in Denver; I've even have a few things on my IMDB page, which doesn't have pics up since I don't have the time. I don't even have Facebook/Twitter since I don't have the time either. 5) I don't have 5k posts on this forum from talking politics! I know SM pretty well. It would take you months & perhaps a year to get to the SM-knowledge level of oddson or me.

If you want quality helpers, they're likely busy with other things; this is the way life is. If you want me to squeeze more time into something, I'll have to squeeze something out, eg comp what I'd be losing from cutting out other jobs. I'm open to exchanges though.

trogluddite · 28 Apr 2010

Here's my take on a possible parser module. The format of the numerics that set the intervals are cumlulative - AFAIK there aren't any chords where two succesive notes are 10 or more semitones apart, so the codeing can be done with single digits. (please let me know if this is wrong, my music theory is terrible!) So the code 1234 means 'two adjacent notes, then up two, then up three'. As many indicators as are neede for the display can be just chained together - it should be possible to have each of these read an array of note names and then sum the resulting strings to get the note names for the chords. The number of intervals is completely flexible. Hope the schematic makes sense - it's very rough and ready (and there's no attempt at a GUI)

P.S. switch and indicators values start at 1 rather than zero - the chained modules use a 'lock any non-zero value' method to read the busses between them.

oddson · 28 Apr 2010

trogluddite wrote: ... So the code 1234 means 'two adjacent notes, then up two, then up three'. As many indicators as are needed for the display can be just chained together - it should be possible to have each of these read an array of note names and then sum the resulting strings to get the note names for the chords. ...

AFAIK you'd still need a green loop to parse through those digits (or use some complex arrangment of modulus division or some string trick) and I suspect the built-in comma-delim-to-string-array feature would be quicker. I did think about storing intervals between members but I think offsets from the root is clearer/cleaner and the issue of optional notes doesn't muddy the water.

trogluddite · 29 Apr 2010

oddson wrote: AFAIK you'd still need

Why the future tense? - the .osm is there now, try it, it works - within the bounds of only having spent half a hour on it at least. String 'trick' yes, loop yes, but not complex - and the loop is only ever as long as the number of notes, so not as many triggers as you might think. (Semantic question - is there such a thing as 'trickery' in programming? Surely an algorithm either does what you want or not, silicon wafers are immune to deception and tomfoolery) Not sure I see a problem with using the intervals this way, maybe that's because I'm used to counting guitar frets rather than keys - but certainly I was taught scales as patterns of intermediate intervals. This way also saves space in the array, and does away with needing to keep track of how many notes there are in each chord. Seems to me pretty economical with primitives too.

Not perfect for sure, but at least practical rather than just theory. I have some other ideas for using this (Attic inspired me with his 'experimental music' thread), so I'll keep at it - there are a lot of different approaches to this little problem; it will be interesting to have a few being developed in parallel - we can test the theory of convergent evolutiion!

oddson · 29 Apr 2010

I didn't notice there was an example file... I was on a break at work and fired off that response without due care.

As for 'tricks' - didn't mean it to be a pejorative... I'm all about tricks.

What I said (or at least meant) is you'd have to use a green loop anyway - which you did - or use modulus math or some string trick (operative word being 'string' implying it is likely to cost about the same as a loop.)

trogluddite · 29 Apr 2010

No offence was taken at all - I'm always at my most pedantic in the early hours!