Hello,
Is there a way to remove duplicate elements for a list? I can figure out how to do it in code, but trying to figure out a way to do this with lists just makes my head hurt.
I want to do Boulez-style pitch-set multiplication with lists, and typically after such an operation, duplicate elements are removed.
I already made an abstraction called "Schoenberg" which I will post shortly, which allows one to do basic serial operations using lists (ie. transposition, retrograde, inversion, and rotation, all using one simple abstraction). I know that serialism has been out of style for 40 years, but nevertheless those methods make a lot of sense to have available, if one is making nontonal generative/aleatoric music.
~David
interesting application... i'd start with serializing a list through [change] & re-packing or list-appending it.
more complicated list operations I find are easier to work with in tables, but I suppose that's a matter of personal preference. Technically (as I understand it, correct me if I'm wrong) they're the same thing. I've got some boolean table abstractions that might be of use - inspired by an article in the CMJ a few months back, I did an implementation of Xenakis' seive device, but haven't used it much in my own stuff since, but I remember implementing a "uniqueness"-filter for tables a while back too.
Hope that helps.
David
On 5/3/06, David Powers cyborgk@gmail.com wrote:
Hello,
Is there a way to remove duplicate elements for a list? I can figure out how to do it in code, but trying to figure out a way to do this with lists just makes my head hurt.
I want to do Boulez-style pitch-set multiplication with lists, and typically after such an operation, duplicate elements are removed.
I already made an abstraction called "Schoenberg" which I will post shortly, which allows one to do basic serial operations using lists (ie. transposition, retrograde, inversion, and rotation, all using one simple abstraction). I know that serialism has been out of style for 40 years, but nevertheless those methods make a lot of sense to have available, if one is making nontonal generative/aleatoric music.
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi david
i once made an abstraction, that outputs a statistic about how many times a certain number was sent to its inlet. i modified it a bit, so that it accepts lists of numbers and gives you a list where duplicate numbers are removed. presumably this is not the fastest method for what you want, but it seems to work.
roman
"David Powers" cyborgk@gmail.com wrote:
Is there a way to remove duplicate elements for a list? I can figure out how to do it in code, but trying to figure out a way to do this with lists just makes my head hurt.
hi list,
I'd like to know if there is a way to force ctlin to accept values greater than 127?
I'm trying to use a midi controller to set a vertical slider but the default 127 units are not precise enough so I set up my midi controller to send 0 to 1000 instead of 0 to 127 but ctlin increments the value from 0 to 127 and then gets back to 0 while the midi controller is at 128 and ctlin starts again from 0 to 127.
any idea would help a lot :)
AshK
hi
On 5/5/06, AshK ashk@azylum.net wrote:
I set up my midi controller to send 0 to 1000 instead of 0 to 127 but ctlin increments the value from 0 to 127 and then gets back to 0 while the midi controller is at 128 and ctlin starts again from 0 to 127. any idea would help a lot :)
2 things come to mind:
- use OSC
- modify source for ctlin to achieve the behavior you want
good luck!
-- \js [ http://or8.net/~johns/ ]
Usually the controller numbered 32 after the 'coarse' controller is the 'fine' controller for the same slider, so for example you could do: [ctlin 1] [ctlin 33] | | [* 128] [t b f] | | [+ ] | [0-16383\
Martin
AshK wrote:
hi list,
I'd like to know if there is a way to force ctlin to accept values greater than 127?
I'm trying to use a midi controller to set a vertical slider but the default 127 units are not precise enough so I set up my midi controller to send 0 to 1000 instead of 0 to 127 but ctlin increments the value from 0 to 127 and then gets back to 0 while the midi controller is at 128 and ctlin starts again from 0 to 127.
any idea would help a lot :)
AshK
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Ash,
AshK wrote:
I'd like to know if there is a way to force ctlin to accept values greater than 127?
Is your MIDI controller REALLY sending messages with higher precision than 0-127? The only way I thought that was possible with the hardware MIDI spec was by using the pitchbend controller, which uses two channels for double-precision AFAIK. So, you could try to use bendin and send the information as a pitchbend message which has higher resolution than a continuous controller. Or you could split the data onto different CC channels and sum them together. Or you could find someone to modify the ctlin object to make it do what you want.
best, d.
hi,
Am Freitag, 5. Mai 2006 17:47 schrieb derek holzer:
Hi Ash,
AshK wrote:
I'd like to know if there is a way to force ctlin to accept values greater than 127?
Is your MIDI controller REALLY sending messages with higher precision than 0-127? The only way I thought that was possible with the hardware MIDI spec was by using the pitchbend controller, which uses two channels for double-precision AFAIK. So, you could try to use bendin and send the
nah ... its using a two byte message ... bitch bend is status 0xEc <lsb><msb>, where c is the channel number (lower nibble of command byte)
together it forms a 14 bit controller message.
note that 0xf2 is globally a song-position message that also uses two bytes (14 bits), but is available only once, since it works on all channels.
so, by using _standard_ midi messages, it is possible to address 17 controller messages with 14 bit each on one cable.
information as a pitchbend message which has higher resolution than a continuous controller. Or you could split the data onto different CC channels and sum them together. Or you could find someone to modify the ctlin object to make it do what you want.
best, d.
or use something else that doesnt use midi at all, to overcome that problem and have a higher speed. there are serveral options available. and if you really need anything special, im sure i can build it for you ... well, at least the electronics for it ... usb is just fun for these things ...
greets,
chris
Hi AshK Can your controller be set to send NRPN data? If so check the list archive for
"Re: [PD] 14bit midi. nrpn and ctlin"
this is what i used to get better resolution from a bcf2000 controller. All the best Nicky
On 5 May 2006, at 17:27, Christian Klippel wrote:
hi,
Am Freitag, 5. Mai 2006 17:47 schrieb derek holzer:
Hi Ash,
AshK wrote:
I'd like to know if there is a way to force ctlin to accept values greater than 127?
Is your MIDI controller REALLY sending messages with higher precision than 0-127? The only way I thought that was possible with the hardware MIDI spec was by using the pitchbend controller, which uses two channels for double-precision AFAIK. So, you could try to use bendin and send the
nah ... its using a two byte message ... bitch bend is status 0xEc <lsb><msb>, where c is the channel number (lower nibble of command byte)
together it forms a 14 bit controller message.
note that 0xf2 is globally a song-position message that also uses two bytes (14 bits), but is available only once, since it works on all channels.
so, by using _standard_ midi messages, it is possible to address 17 controller messages with 14 bit each on one cable.
information as a pitchbend message which has higher resolution than a continuous controller. Or you could split the data onto different CC channels and sum them together. Or you could find someone to modify the ctlin object to make it do what you want.
best, d.
or use something else that doesnt use midi at all, to overcome that problem and have a higher speed. there are serveral options available. and if you really need anything special, im sure i can build it for you ... well, at least the electronics for it ... usb is just fun for these things ...
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
thank you all for your answers in and off-list I will try your solutions and as the controller I'm trying to work with is a bcf2000 I will try your solution first Nicky thanks a lot!
AshK
On Fri, 5 May 2006 20:23:32 +0100 Nicholas Ward nicholas.ward@cs.tcd.ie wrote:
Hi AshK Can your controller be set to send NRPN data? If so check the list archive for
"Re: [PD] 14bit midi. nrpn and ctlin"
this is what i used to get better resolution from a bcf2000 controller. All the best Nicky
On 5 May 2006, at 17:27, Christian Klippel wrote:
hi,
Am Freitag, 5. Mai 2006 17:47 schrieb derek holzer:
Hi Ash,
AshK wrote:
I'd like to know if there is a way to force ctlin to accept values greater than 127?
Is your MIDI controller REALLY sending messages with higher precision than 0-127? The only way I thought that was possible with the hardware MIDI spec was by using the pitchbend controller, which uses two channels for double-precision AFAIK. So, you could try to use bendin and send the
nah ... its using a two byte message ... bitch bend is status 0xEc <lsb><msb>, where c is the channel number (lower nibble of command byte)
together it forms a 14 bit controller message.
note that 0xf2 is globally a song-position message that also uses two bytes (14 bits), but is available only once, since it works on all channels.
so, by using _standard_ midi messages, it is possible to address 17 controller messages with 14 bit each on one cable.
information as a pitchbend message which has higher resolution than a continuous controller. Or you could split the data onto different CC channels and sum them together. Or you could find someone to modify the ctlin object to make it do what you want.
best, d.
or use something else that doesnt use midi at all, to overcome that problem and have a higher speed. there are serveral options available. and if you really need anything special, im sure i can build it for you ... well, at least the electronics for it ... usb is just fun for these things ...
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No need to search the list. Just use the mccallum abstractions:
http://www.mentalfloss.ca/sintheta/html/downloads.html
Jamie
On Sat, 6 May 2006 11:54:58 +0200 AshK ashk@azylum.net wrote:
thank you all for your answers in and off-list I will try your solutions and as the controller I'm trying to work with is a bcf2000 I will try your solution first Nicky thanks a lot!
AshK
On Fri, 5 May 2006 20:23:32 +0100 Nicholas Ward nicholas.ward@cs.tcd.ie wrote:
Hi AshK Can your controller be set to send NRPN data? If so check the list archive for
"Re: [PD] 14bit midi. nrpn and ctlin"
this is what i used to get better resolution from a bcf2000 controller. All the best Nicky
On 5 May 2006, at 17:27, Christian Klippel wrote:
hi,
Am Freitag, 5. Mai 2006 17:47 schrieb derek holzer:
Hi Ash,
AshK wrote:
I'd like to know if there is a way to force ctlin to accept values greater than 127?
Is your MIDI controller REALLY sending messages with higher precision than 0-127? The only way I thought that was possible with the hardware MIDI spec was by using the pitchbend controller, which uses two channels for double-precision AFAIK. So, you could try to use bendin and send the
nah ... its using a two byte message ... bitch bend is status 0xEc <lsb><msb>, where c is the channel number (lower nibble of command byte)
together it forms a 14 bit controller message.
note that 0xf2 is globally a song-position message that also uses two bytes (14 bits), but is available only once, since it works on all channels.
so, by using _standard_ midi messages, it is possible to address 17 controller messages with 14 bit each on one cable.
information as a pitchbend message which has higher resolution than a continuous controller. Or you could split the data onto different CC channels and sum them together. Or you could find someone to modify the ctlin object to make it do what you want.
best, d.
or use something else that doesnt use midi at all, to overcome that problem and have a higher speed. there are serveral options available. and if you really need anything special, im sure i can build it for you ... well, at least the electronics for it ... usb is just fun for these things ...
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
\js -
AshK -
Christian Klippel -
david golightly -
David Powers -
derek holzer -
Jamie Bullock -
Martin Peach -
Nicholas Ward -
Roman Haefeli