Offsetting output from coll
Hi
Got a real simple patch and hopefully a simple problem too! I'm trying to unpack from a coll object and then offsetting each value in the array by the same amount, and then packing them back togther to write a list for a chord.
So I've got a coll object with say
1, 0 3 5
2, 3 5 7
3, 5 7 9 12
That's the interval spacings for some chord voicing's, so basically what my patch does is add an offset value to each of the items in the list, so if offset is 60 = 60 63 65 yay!
All is good except when the list from the coll is not the same length as the previous entry, the integers in the list linger if I switch to a list with a smaller size. Given that the list length varies I've had to use an unpack and pack object with enough in's to accommodate, but when I switch the coll and the list is a smaller list size, the values from the longer list linger around in the message box.
Is there any way to essentially flush out the numbers that are the same when changing list? Or some sort of compare and filter if the same value is offset, I've tried with zl filter, but didn't work maybe because of this hot/cold thing and wasn't trigger banging it!
`
As always any help would be greatly appreciated. Thanks!
Sorry there was a bug with the patch I made above, forgot to pack velocity for each note.
Here's a better version `
But still the original problem is there, I have had to use an unpack with four inputs, for instance unpack 0 0 0 0, and every row in the coll needs to have four items, not sure how to approach it if I have an arbitrary amount of items in the coll. Would I need an unpack object with enough inputs to match the maximum the length of the list will be?
The main object you need to be aware of is [iter]. (See example.) Each note can then be transposed, packed with a note-on velocity, and sent on to [flush]. There's also an object called [vexpr] for performing arithmetic expressions on lists of numbers, so I've included a demonstration of that object in the example, too.
whoa thankyou so much, this is very exciting. I'm just wondering about something in the patch you made, you've made two implementations that do exactly the same thing with different objects right? One forces the chord to play when the list number is changed, the other requires to bang the chord message through vxepr? The latter is how I need it to work in the end, as i'm trying to make a harmoniser type thing, so a melody note comes in, it changes the list number in coll, but only triggers when the user wants, with a bang/midi note.
I'm not entirely sure how to you would adapt the right hand implementation to only trigger the chord when there is a bang. I could just use the left hand implementation, but I'm really unfamiliar with this hot/cold and forcing calculation concept, so this might be a good chance to ask a pro about this concept. I get it a bit, just shaky on the mechanics of what is really happening or how to stop it happening when you want.
`
Also thank you so much for your help, actually overwhelmed by the love and generosity of this forum, you are a ninja legend monster! ninjendster!
In my example, I just wanted to demonstrate the idea, so I made the [metro] object to provide the bang messages that cause the [urn] object to send out a random choice of chord voicing. But there's no inherent reason that the choice has to be made at the same moment you want to trigger the result. You can just hold onto that number until the moment when you actually want to use it.
ahh right I think I get it, so that [i] is identical to the int object?
Thank you so much, sorry for the silliest of questions, better to ask than forever be confused!