New Midi VST project - Progressilator

caleb · 11 Dec 2006

The first thing I'm trying to fix up is that switching a major to a minor really requires more than just flattening a third from the major scale.

You also need to flatten the 6th.

I could say - if semitone in octave equals 4 (with 0 being the tonic) - subtract one from the note value.

Then I could have another compare saying if the semitone in octave equals 9 - subtract one from the note value.

I'm wondering if there's a better way.

For example if value is in list of values, subtract one from the note value.

I'm probably thinking too high up in Python land where this stuff is easy from a programming point of view - but it's probably just performing a series of if-then instructions lower down anyway.

I've been playing with the idea of using an array of integers and a loop primitive, but I think that will end up being a wanky idea so I'm dropping in favour of the string of if-thens.

What I do need though is a way to "execute" chunks of my schematic based on a choice. Ie - I want to be able to say - if the selection for destination is minor go into this module that determines which notes need to be changed for a minor.

I think the Multiplex module might be it - not 100% sure, but I'll experiment and see if this brings about the desired result.

Regards Caleb

unkargherth · 11 Dec 2006

caleb wrote: I've been playing with the idea of using an array of integers and a loop primitive, but I think that will end up being a wanky idea so I'm dropping in favour of the string of if-thens.

Seems agood idea for me. Generate a colection of arrays at begining, each one containing the distance in semitones from tonic fro every interesting note

Then, when you need , ie a minor chord, simply select wich array you wanna use

I think is far more eficient than evaluate a collectio of if in any change of "mode"

Also better if you plan to implement a big colection of modes ( Major, minor, 7th, 5th aug , 4th dim, 9th,11th,13th,etc)

caleb · 11 Dec 2006

Well the big collection of modes isn't going to be a problem because I'm using a multiplex to divert into the appropriate modes based on mode is selected.

So if I select min, the signal gets routed to the "make it minor" module, if I select 7th, the signal gets routed to the "make it 7th" module etc...

So I shouldn't really need huge long strings of if-then.

So minor now has if it's 4, then flatten, if it's 9, then flatten. This isn't too unwieldy.

The 7th is only flattening the 11th semitone so it's not a problem.

It might be a good idea to make an array, but it's not really clear to me how to use this properly. Once I've played with it a bit more I might find better ways to use it. Even creating the array seems a little strange to me.

Regards Caleb

infuzion · 11 Dec 2006

unkargherth wrote: Generate a colection of arrays at begining, each one containing the distance in semitones from tonic fro every interesting note

Then, when you need , ie a minor chord, simply select wich array you wanna use

That's the way I would do it! Might beable to cut & paste in an array from a spread sheet, with a bit of .txt exporting...

caleb · 11 Dec 2006

Thanks for the suggestions about the arrays. Unfortunately, I really just don't know how to implement what you're speaking about. I think I'm going to need to understand arrays and iterators better in SM but they're just curiosities to me at the moment.

Regards Caleb

infuzion · 11 Dec 2006

Hmmm after adding a few things to Jorge's Chord.osm from here: Chord & oddson's String2Array [old link] I came up with this: [old link]

also interesting: chord or multiple note string

caleb · 11 Dec 2006

I've been working with the string2array module trying to understand it. I've modified it so that it stores a list of comma separated values into an integer array, but I'm having a problem with the clear trigger on the array.

The module stores all my values into an array of integers but the clear trigger is arriving afterwards and clearing all the values.

In the string2array module, the incoming string triggers the clear of the string array. Likewise, my incoming string triggers the clear of the integer array. But in my case, the clear seems to be coming too late. 🙁

This is a link to my modification.

http://cbdevices.calebblake.com/files/string2intarray.osm

If anyone can tell me why I'm having the clear problem I'd be much obliged.

Regards Caleb

infuzion · 11 Dec 2006

caleb wrote: In the string2array module, the incoming string triggers the clear of the string array. Likewise, my incoming string triggers the clear of the integer array. But in my case, the clear seems to be coming too late. If anyone can tell me why I'm having the clear problem I'd be much obliged.

It's your link order. Look inside the module at the In. You'll see little notches next to it on each link. This is telling the programmer (you) what order that In data goes out. So, you need to make the Array:Clear trigger the first to recieve data, then Counter:Reset , then the module. {edit}

caleb · 11 Dec 2006

Oh cripes!

That's simple and it certainly makes sense. I didn't go past thinking - that's the first additional, that's the second additional.....

This visual logic is simple once you actually start thinking! 😀

Thanks for that. Off to bed now, but I'll fix up what I've done some time tomorrow and move ahead with redesigning using arrays.

Thanks for the help.

Regards Caleb

caleb · 12 Dec 2006

Was just thinking about the problems attached with transposing via different modes.

Now that people and previous efforts have got me using integer arrays I will be able to move from major to minor and minor to major fairly easily.

However, chords like 7 and min7 are a little different, and it's made me realise that I need to cater for two different types of pattern used as input: melody and chord.

For a melody track it's fine to just flatten or sharpen as necessary. However, for chord-type tracks you'll want to add and/or remove notes . Additionally, in one pattern you may have a melody and a chord component. So it might be worthwhile to introduce an automatable switch between the two transposition methods.

The saga continues....

Regards Caleb

caleb · 12 Dec 2006

Putting aside all other fancy features this thing could have, I have an issue with how the Progressilator currently performs.

The idea of this device is meant for realtime transposition to different keys based on a base (root) pattern.

I have it so that the destination key can be automated via CC, or switchable by midi note on a separate channel from the base pattern.

However, I get all sorts of horrific stuck notes when the destination key is altered at the same time as a note is being played in the base pattern.

Eg. Base pattern sends a C3 minim to the Progressilator and exactly the same time as automation is sent to change the destination key. This will result in C3 becoming stuck.

I can avoid this if I send the automation data after one note off and before the next note on, but this isn't terribly practical - especially as there won't always be such a gap between notes in the base pattern.

So this is my next challenge.

Regards Caleb