For the unpack object, now in the coll object we have 3 numbers ( counter, x point and y point) and we are unpacking into 2 number, so which number do get selected in that? :S
@mudithead Not sure I follow you. Of the three numbers, the first is the index (which counter counts through). It then spits out whatever is stored at that index (x point and y point). Is that what you mean?
@MUST1002 Yes, okay, so you mean the 'unpack' object knows that the 3 number stored in the 'coll automation' out of which the first is the index, and then the its respective x & y point? since we are writing 'unpack 0 0' and not 'unpack 0 0 0' .
@mudithead If you run the output of the left-hand output of [coll] to a [print] object you'll see that it only outputs two values, i.e. what is _stored_ at the index, _not_ the index number itself (the index number is actually sent out of the second outlet of [coll]). Since there are only two numbers coming out of [coll] (as a list), we only need two values in the [unpack] object, hence [unpack 0 0].
I've got stuck at this patch when using it as a reference comparing it to a patch I've built, trying to tidy a few things up. Basically I want to smooth some things out with my line object & you example here would be perfect but I'm using 'xn' values for my metro (eg. 4n) and figure I won't be able to write those into my pack objects as arguments. Do you have have advice for me to get around this?
@wirezts I'm not entirely sure what you're aiming to do. But you could work with numbers thru' the [line] object and then convert to 'xn' values subsequently ([sprintf] is useful for this—e.g. [sprintf %in] would convert whatever integer it receives to 1n, 2n, 3n etc (remember, though, that intermediary values (3n, 5n, 6n, 7n, 9n etc) won't give you useful output from [metro]. But I might be misinterpreting how you want to do this anyway...
@MUST1002 Thanks for the quick reply. Basically I want my line objects' ramp to be the same speed as my metro as you have done, but on my metro I use 'quantise' arguments, eg. 1n, 2n, 4n, 8n - defined by the transport. So I need a way to convert the '4n' from my metro back into a number that can be used in my line object. I think '$' value will be involved as the number will change based on the tempo of the transport. Sorry if I'm still not explaining it very well, hope you can help!
@wirezts Hmm. Have you tried the [translate] object? You can use this to convert your relative time value (e.g. 4n) to absolute (e.g. ms —it'll change the calc if you change the bpm). You can then perhaps send _that_ value to [line]...
Again, I might not be understanding you right so apologies if the above is useless.
Hey, :)
For the unpack object, now in the coll object we have 3 numbers ( counter, x point and y point) and we are unpacking into 2 number, so which number do get selected in that? :S
mudithead 5 months ago
@mudithead Not sure I follow you. Of the three numbers, the first is the index (which counter counts through). It then spits out whatever is stored at that index (x point and y point). Is that what you mean?
MUST1002 5 months ago
@MUST1002 Yes, okay, so you mean the 'unpack' object knows that the 3 number stored in the 'coll automation' out of which the first is the index, and then the its respective x & y point? since we are writing 'unpack 0 0' and not 'unpack 0 0 0' .
mudithead 5 months ago
@mudithead If you run the output of the left-hand output of [coll] to a [print] object you'll see that it only outputs two values, i.e. what is _stored_ at the index, _not_ the index number itself (the index number is actually sent out of the second outlet of [coll]). Since there are only two numbers coming out of [coll] (as a list), we only need two values in the [unpack] object, hence [unpack 0 0].
MUST1002 5 months ago
Hi mate,
I've got stuck at this patch when using it as a reference comparing it to a patch I've built, trying to tidy a few things up. Basically I want to smooth some things out with my line object & you example here would be perfect but I'm using 'xn' values for my metro (eg. 4n) and figure I won't be able to write those into my pack objects as arguments. Do you have have advice for me to get around this?
wirezts 8 months ago
@wirezts I'm not entirely sure what you're aiming to do. But you could work with numbers thru' the [line] object and then convert to 'xn' values subsequently ([sprintf] is useful for this—e.g. [sprintf %in] would convert whatever integer it receives to 1n, 2n, 3n etc (remember, though, that intermediary values (3n, 5n, 6n, 7n, 9n etc) won't give you useful output from [metro]. But I might be misinterpreting how you want to do this anyway...
MUST1002 8 months ago
@MUST1002 Thanks for the quick reply. Basically I want my line objects' ramp to be the same speed as my metro as you have done, but on my metro I use 'quantise' arguments, eg. 1n, 2n, 4n, 8n - defined by the transport. So I need a way to convert the '4n' from my metro back into a number that can be used in my line object. I think '$' value will be involved as the number will change based on the tempo of the transport. Sorry if I'm still not explaining it very well, hope you can help!
wirezts 8 months ago
@wirezts Hmm. Have you tried the [translate] object? You can use this to convert your relative time value (e.g. 4n) to absolute (e.g. ms —it'll change the calc if you change the bpm). You can then perhaps send _that_ value to [line]...
Again, I might not be understanding you right so apologies if the above is useless.
MUST1002 8 months ago
@MUST1002 Ah of course, forgot about the translate object!! Thanks a lot mate :D
wirezts 8 months ago