Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
~David
You might want to look at the bitwise operators >>, <<, etc. I tried to play with them after some summer flirtation I had with the R&K C manual, but never got far with that concept. ~Kyle
On 3/16/07, David Powers cyborgk@gmail.com wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<<
and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
You must implement the algorithm shown in this link:
http://en.wikipedia.org/wiki/Binary_numeral_system#Decimal
I did that in C during that earlier mentioned summer of my K&R C binge. I'm not sure how tricky it would be to do in Pd.
~Kyle
On 3/16/07, David Powers cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow I thought for sure this would be built in ... or at least a common external.
It kind of defeats the point of using bitwise operations, if I have to do a conversion with some PD list algorithm, because the whole point was to avoid list operations in PD, in order to speed things up! It would be easy enough to do though: tabdump, for every position that is 1, raise 2 to the i power (where i is the index of the position), and add up the results.
I guess speed is the issue here for me, rather than the ability to convert per se. This would be a good reason to write my first external I guess.
~David
On 3/16/07, Kyle Klipowicz kyleklip@gmail.com wrote:
You must implement the algorithm shown in this link:
http://en.wikipedia.org/wiki/Binary_numeral_system#Decimal
I did that in C during that earlier mentioned summer of my K&R C binge. I'm not sure how tricky it would be to do in Pd.
~Kyle
On 3/16/07, David Powers cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
On Fri, 16 Mar 2007 13:18:12 -0600 "David Powers" cyborgk@gmail.com wrote:
Wow I thought for sure this would be built in ... or at least a common external.
It possibly is. I'm just showing you how to do it from scratch in a way that directly follows the algorithm Kyle pointed you at.
You could use << and >> to rotate your numbers, and other ways to do it differently. Making it extensible/flexible so that you can work on 8, 16, 32 or bigger rythmns is an important consideration, and you usualy end up using lists to do that or adopt a fixed width approach.
I guess speed is the issue here for me, rather than the ability to convert per se.
The binary representation of beats has come up before, several times and although it is seductive as an apparently efficient data structure it has a bunch of its own pitfalls and weaknesses that I'm sure you will have fun discovering :) As for speed, I don't think the conversion stage is where you will gain much opimisation anyway if your premise is to save cycles by doing bitwise transformations on integers.
This would be a good reason to write my first external I guess.
Yes it would be a good task to do. It's quite trivial in C. You could make a simple and general [bit n] that returns the nth bit of a decimal int on its left inlet. To do it properly and make it maintainable perhaps some arguments for byte/word size and endiness would help.
~David
On 3/16/07, Kyle Klipowicz kyleklip@gmail.com wrote:
You must implement the algorithm shown in this link:
http://en.wikipedia.org/wiki/Binary_numeral_system#Decimal
I did that in C during that earlier mentioned summer of my K&R C binge. I'm not sure how tricky it would be to do in Pd.
~Kyle
On 3/16/07, David Powers cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'll try to dig up my c code and give it to you, in exchange for GPL.
~Kyle
On 3/17/07, padawan12 padawan12@obiwannabe.co.uk wrote:
On Fri, 16 Mar 2007 13:18:12 -0600 "David Powers" cyborgk@gmail.com wrote:
Wow I thought for sure this would be built in ... or at least a common external.
It possibly is. I'm just showing you how to do it from scratch in a way that directly follows the algorithm Kyle pointed you at.
You could use << and >> to rotate your numbers, and other ways to do it differently. Making it extensible/flexible so that you can work on 8, 16, 32 or bigger rythmns is an important consideration, and you usualy end up using lists to do that or adopt a fixed width approach.
I guess speed is the issue here for me, rather than the ability to convert per se.
The binary representation of beats has come up before, several times and although it is seductive as an apparently efficient data structure it has a bunch of its own pitfalls and weaknesses that I'm sure you will have fun discovering :) As for speed, I don't think the conversion stage is where you will gain much opimisation anyway if your premise is to save cycles by doing bitwise transformations on integers.
This would be a good reason to write my first external I guess.
Yes it would be a good task to do. It's quite trivial in C. You could make a simple and general [bit n] that returns the nth bit of a decimal int on its left inlet. To do it properly and make it maintainable perhaps some arguments for byte/word size and endiness would help.
~David
On 3/16/07, Kyle Klipowicz kyleklip@gmail.com wrote:
You must implement the algorithm shown in this link:
http://en.wikipedia.org/wiki/Binary_numeral_system#Decimal
I did that in C during that earlier mentioned summer of my K&R C binge. I'm not sure how tricky it would be to do in Pd.
~Kyle
On 3/16/07, David Powers cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
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
binary to decimal, just raise the nth bit 2^^n, decimal to binary see attached (done from Kyles link) - problem: the list is a variable length and you probably want to pad it with zeros for whatever word length you have.
On Fri, 16 Mar 2007 12:17:02 -0600 "David Powers" cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Please, I appreciate the answers, but again this isn't what I'm looking for, because your method provides no speed gain, and thus no reason to implement my idea. I was assuming there was some object coded in C to do the conversion already in existence. I already know how to do it "manually" in PD. But there's no point in doing binary shift if it requires conversion through PD abstractions. I can just achieve the same result with a simple list operation.
PD always kills my work laptop CPU (WinXP with Pentium M), so if I'm ever gonna do serious audio with it, speed is fairly crucial...
~David
On 3/17/07, padawan12 padawan12@obiwannabe.co.uk wrote:
binary to decimal, just raise the nth bit 2^^n, decimal to binary see attached (done from Kyles link) - problem: the list is a variable length and you probably want to pad it with zeros for whatever word length you have.
On Fri, 16 Mar 2007 12:17:02 -0600 "David Powers" cyborgk@gmail.com wrote:
Hi, sorry I do know that, but it's not my question.
In order to use the bitwise operators, I think I need to convert an arbitrary string of 0's and 1's, say "00010101", into an integer, in this case I think 21. Is that more clear?
Thanks, David
On 3/16/07, Steffen stffn@dibidut.dk wrote:
On 16/03/2007, at 18.44, David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
I think you want to have a look at the bitwice operators &,&&,|,||,<< and >>. See also http://en.wikipedia.org/wiki/Bitwise_operation
Hope this helps.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
David Powers wrote:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
just to chime in: pd internally uses 32bit floats, which will make your idea troublesome to implement as soon as you want patterns longer than (...cannot rembmer right now).
you could always use zexy's [symbol2list] to convert a symbol [+-+-+---+-++] into a list of symbols + - + - + - - - + - + + which can then easily be passed with a kind of [drip] (or [list/drip] into a [select] in order to trigger stuff.
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
David Powers wrote:
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
just to chime in: pd internally uses 32bit floats, which will make your idea troublesome to implement as soon as you want patterns longer than (...cannot rembmer right now).
you could always use zexy's [symbol2list] to convert a symbol [+-+-+---+-++] into a list of symbols + - + - + - - - + - + + which can then easily be passed with a kind of [drip] (or [list/drip] into a [select] in order to trigger stuff.
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats are always 1 or 0 there won't be any problems with long strings.
Martin
Martin Peach wrote:
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats are always 1 or 0 there won't be any problems with long strings.
in theory this is correct. nevertheless, when saving a patch containing a "string" (this is: a symbol) "101", pd will eventually parse this as number 101.0 on re-loading the patch. therefore i proposed a truly symbolic representation.
of course you could also use some prefix to enforce it a symbol, like #100110100, but then you have an additional character just to workaround pd's limitations with string handling. using +--++-+- (or IOIIIOIOI, or ...) is cleaner in a sense that it totally represents the 101001 scheme but deals (as opposed to works around) pd's shortcomings.
mfga.sdr IOhannes
I have some abstractions now all together with help - both for conversions and for rhythm manipulation. Will post later when I get home, I don't have my laptop right now...
~David
Attached please find what I have so far...
[bin2dec] [dec2bin] [ptn_shift] to demonstrate what I was getting at in terms of rhythms...
And unfinished help files to accompany/test.
~David
On 3/17/07, David Powers cyborgk@gmail.com wrote:
I have some abstractions now all together with help - both for conversions and for rhythm manipulation. Will post later when I get home, I don't have my laptop right now...
~David
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats are always 1 or 0 there won't be any problems with long strings.
in theory this is correct. nevertheless, when saving a patch containing a "string" (this is: a symbol) "101", pd will eventually parse this as number 101.0 on re-loading the patch. therefore i proposed a truly symbolic representation.
Sorry to confuse; I meant my patch to pd that implements strings in pd. Assuming you have a version of pd with string support and have the [str] external as well, if you write the string with spaces between the numbers, the string will consist of zeros and ones (as bytes). (without the spaces it would be interpreted as a sequence containing the characters 1 and 0, i.e. 49 and 48) The string won't be saved in the patch, but the arguments to the [str] object will, and since they are 0 and 1 they won't be clipped or misinterpreted even if there are a lot of them. This is not part of pd (yet). This is yet another application where it could be useful... See http://pure-data.cvs.sourceforge.net/pure-data/packages/patches/add_string_s... and http://pure-data.cvs.sourceforge.net/pure-data/externals/mrpeach/str/
of course you could also use some prefix to enforce it a symbol, like #100110100, but then you have an additional character just to workaround pd's limitations with string handling. using +--++-+- (or IOIIIOIOI, or ...) is cleaner in a sense that it totally represents the 101001 scheme but deals (as opposed to works around) pd's shortcomings.
That would work too. Is there a limit to the length of such a symbol?
Martin
mfga.sdr IOhannes
Martin Peach wrote:
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats
then why the hell do you need [str drip]? there is no stringish content in your example, so you could as well use pure pd objects (see frank's list abstractions), or zexy's [drip] & [repack] (which are as well externals as your [str] but don't require pd to be patched).
are always 1 or 0 there won't be any problems with long strings.
in theory this is correct. nevertheless, when saving a patch containing a "string" (this is: a symbol) "101", pd will eventually parse this as number 101.0 on re-loading the patch. therefore i proposed a truly symbolic representation.
no, i don't think so.
even though i haven't looked closely at your "string"-implementation (which really should be called "blob" rather than "string", imho), i doubt whether it interferes at all with pd's saving mechanism which is the problem here (at least: which is the problem i am talking about).
the internal symbol representation is an as "truly symbolic representation" as your strings are there are other problems with symbols, like the infinetely growing hash-table; this is (to my knowledge) somewhat addressed by your strings; but this has nothing to do with the problem of storing the token "000001" in pd: at the best it will be stored as "000001", but on loading the patch it will be become "1" (which might be appropriate, but might as well not).
That would work too. Is there a limit to the length of such a symbol?
no there is not. (but there is a limit to what pd will display via [print] or in message/symbol-boxes. but the symbols can be any lengths)
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats
then why the hell do you need [str drip]? there is no stringish content in your example, so you could as well use pure pd objects (see frank's list abstractions), or zexy's [drip] & [repack] (which are as well externals as your [str] but don't require pd to be patched).
The string in my example is the string of digits. Yes, I would personally just use a row of toggles. It simplifies inputting values, I can't imagine anyone starting with a decimal representation of a binary string to define a rhythm, what they want is the other way around.
are always 1 or 0 there won't be any problems with long strings.
in theory this is correct. nevertheless, when saving a patch containing a "string" (this is: a symbol) "101", pd will eventually parse this as number 101.0 on re-loading the patch. therefore i proposed a truly symbolic representation.
no, i don't think so.
even though i haven't looked closely at your "string"-implementation (which really should be called "blob" rather than "string", imho)
I did it to see if it would work, the name is irrelevant to me. I guess as far as string implies text, it was a bad idea. The object manages a list of bytes, so they are strings in the c sense except there is no trailing zero, and in the Pascal sense except that the length is kept beside the string, not in front. The strings may be stored and read from files but they aren't saved in the pd patch except as arguments to the str objects.
, i doubt whether it interferes at all with pd's saving mechanism which is the problem here (at least: which is the problem i am talking about).
the internal symbol representation is an as "truly symbolic representation" as your strings are there are other problems with symbols, like the infinetely growing hash-table; this is (to my knowledge) somewhat addressed by your strings; but this has nothing to do with the problem of storing the token "000001" in pd: at the best it will be stored as "000001", but on loading the patch it will be become "1" (which might be appropriate, but might as well not).
As I said, if it's stored as an argument to a str object, 0 0 0 0 0 1 with spaces in between the digits involves no symbols, only floats. Even if that gets converted to 0.0 0.0 0.0 0.0 0.0 1.0 it won't affect the meaning. The str object doesn't use symbols internally except for the [str tosymbol] variant.
Martin
On Fri, Mar 16, 2007 at 11:44:54AM -0600, David Powers wrote:
Is it possible to somehow convert back and forth between integer and binary in PD?
Hi David,
I know this isn't exactly what you want, but it is along the same lines. I used to enjoy writing beats on graph paper before transcribing them into the computer, and this abstraction is perfect for doing that:
http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-mseq.pd http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-mseq-help.pd
It turns an integer into a binary/trinary/whatever rhythm which you can look up by index.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hi David
I sometimes use constructs like attached patch. Its just a bitmask. Quite effektive for eventfiltering, beatcuts and patterncreation.
more xor!
Interesting that you persue this.
mvh Steffen Leve Poulsen
David Powers skrev:
Hello,
Is it possible to somehow convert back and forth between integer and binary in PD?
My idea, is to represent simple drum machine style rhythms as binary numbers. [101010001011]. Ok, so if this were a float, it would be trivial to do a common task and shift the rhythm left or right. I think, that other rhythmic variations would also be quite fast to implement using this system, you can do binary math instead of list operations which should be much faster, I assume.
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 452 124 801 312 12; #X obj 409 157 & 1; #X obj 369 157 & 2; #X obj 329 157 & 4; #X obj 289 157 & 8; #X floatatom 99 42 5 0 0 0 - - -; #X obj 239 157 & 16; #X obj 192 157 & 32; #X obj 149 157 & 64; #X obj 99 157 & 128; #X obj 99 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 119 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 139 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 32; #X obj 159 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 16 16; #X obj 179 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 199 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 219 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 239 221 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 157 39 <- scroll this; #X floatatom 30 188 5 0 0 0 - - -; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 8 0 18 0;
On 3/18/07, Steffen Leve Poulsen slagmark@worldonline.dk wrote:
Hi David
I sometimes use constructs like attached patch. Its just a bitmask. Quite effektive for eventfiltering, beatcuts and patterncreation.
more xor!
Ah this is interesting - and proof that it's really time I learn dynamic patching ... your approach is probably more efficient, but on the other hard, my approach allows for lists of any length. (Although, I doubt that I'd be doing patterns longer than 64 very often.) Anyway, my point is that with dynamic patching perhaps it would be possible to use your approach, without knowing the length of the list in advance. ~David
list of any length or ints of any size. Here is xor.pd and help-xor.pd (already a classic).
You should tjek out how xor.pd is constructed. I think this is the way to go when its bitwise. You can easily change the int size (list length).
God Luck Steffen Leve Poulsen
David Powers skrev:
Ah this is interesting - and proof that it's really time I learn dynamic patching ... your approach is probably more efficient, but on the other hard, my approach allows for lists of any length. (Although, I doubt that I'd be doing patterns longer than 64 very often.) Anyway, my point is that with dynamic patching perhaps it would be possible to use your approach, without knowing the length of the list in advance. ~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 300 28 797 737 12; #X obj 87 4 inlet; #X obj 263 619 outlet; #X obj 147 227 until; #X msg 147 168 16; #X obj 147 194 t f b; #X msg 282 214 0; #X obj 147 259 f; #X obj 181 260 + 1; #X obj 298 576 f; #X obj 263 575 +; #X obj 199 457 pow; #X msg 199 429 2 $1; #X obj 143 392 f; #X obj 103 392 f; #X obj 103 555 *; #X obj 103 488 &; #X obj 143 488 &; #X obj 148 287 t b b f; #X obj 103 525 !=; #X obj 162 352 inlet; #X obj 87 128 t b f; #X text 272 69 XOR does bitwise xor intersection of two 16 bit integers ; #X text 458 136 XOR:; #X text 429 169 1 xor 1 = 0; #X text 429 199 0 xor 0 = 0; #X text 429 229 1 xor 0 = 1; #X text 429 259 0 xor 1 = 1; #X text 106 669 Steffen Leve Poulsen 2007; #X text 107 689 steffen at menneske dot dk; #X obj 87 36 t b f; #X obj 87 67 del 100; #X obj 87 97 f; #X connect 0 0 29 0; #X connect 2 0 6 0; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 4 1 5 0; #X connect 5 0 6 1; #X connect 5 0 9 1; #X connect 6 0 7 0; #X connect 6 0 17 0; #X connect 7 0 6 1; #X connect 8 0 9 1; #X connect 9 0 8 0; #X connect 9 0 1 0; #X connect 10 0 16 1; #X connect 10 0 15 1; #X connect 10 0 14 1; #X connect 11 0 10 0; #X connect 12 0 16 0; #X connect 13 0 15 0; #X connect 14 0 9 0; #X connect 15 0 18 0; #X connect 16 0 18 1; #X connect 17 0 13 0; #X connect 17 1 12 0; #X connect 17 2 11 0; #X connect 18 0 14 0; #X connect 19 0 12 1; #X connect 20 0 3 0; #X connect 20 1 13 1; #X connect 29 0 30 0; #X connect 29 1 31 1; #X connect 30 0 31 0; #X connect 31 0 20 0;
#N canvas 177 35 1060 501 12; #X obj 753 241 until; #X obj 753 206 unpack f f; #X msg 753 179 256 0; #X obj 753 270 f; #X obj 780 270 + 1; #X obj 753 302 t f f; #X obj 753 424 tabwrite vu; #N canvas 0 0 450 300 (subpatch) 0; #X array vu 256 float 0; #X coords 0 256 255 0 200 140 1; #X restore 442 208 graph; #X obj 913 90 f; #X obj 959 90 + 1; #X obj 913 119 mod 256; #X msg 913 33 40; #X msg 952 34 0; #X obj 913 61 metro; #N canvas 0 0 512 223 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 43 pd tobin; #N canvas 0 0 543 205 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 32 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 50 91 pd tobin; #N canvas 0 0 587 245 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 32 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 171 pd tobin; #X obj 31 138 xor; #X text 575 30 Start to see xor effect on linear ramp ->; #X text 289 87 <- 1 set this numberbox; #X text 289 44 <- 2 set that numberbox; #X text 31 3 XOR does bitwise xor intersection of two 16 bit integers ; #X text 328 196 XOR:; #X text 299 229 1 xor 1 = 0; #X text 299 259 0 xor 0 = 0; #X text 299 289 1 xor 0 = 1; #X text 299 319 0 xor 1 = 1; #X text 26 339 Steffen Leve Poulsen 2007; #X text 27 359 steffen at menneske dot dk; #N canvas 0 0 587 245 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 241 pd tobin; #X obj 753 397 xor; #X obj 31 208 xor; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 1 1 3 1; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 3 0 5 0; #X connect 4 0 3 1; #X connect 5 0 30 0; #X connect 5 1 6 1; #X connect 8 0 10 0; #X connect 9 0 8 1; #X connect 10 0 9 0; #X connect 10 0 2 0; #X connect 10 0 30 1; #X connect 11 0 13 0; #X connect 11 0 13 1; #X connect 12 0 13 0; #X connect 13 0 8 0; #X connect 14 0 17 0; #X connect 15 0 17 1; #X connect 15 0 31 1; #X connect 16 0 31 0; #X connect 17 0 16 0; #X connect 30 0 6 0; #X connect 31 0 29 0;
Just a small correction
Stffn
Steffen Leve Poulsen skrev:
list of any length or ints of any size. Here is xor.pd and help-xor.pd (already a classic).
You should tjek out how xor.pd is constructed. I think this is the way to go when its bitwise. You can easily change the int size (list length).
God Luck Steffen Leve Poulsen
David Powers skrev:
Ah this is interesting - and proof that it's really time I learn dynamic patching ... your approach is probably more efficient, but on the other hard, my approach allows for lists of any length. (Although, I doubt that I'd be doing patterns longer than 64 very often.) Anyway, my point is that with dynamic patching perhaps it would be possible to use your approach, without knowing the length of the list in advance. ~David
#N canvas 177 35 1060 501 12; #X obj 753 241 until; #X obj 753 206 unpack f f; #X msg 753 179 256 0; #X obj 753 270 f; #X obj 780 270 + 1; #X obj 753 302 t f f; #X obj 753 424 tabwrite vu; #N canvas 0 0 450 300 (subpatch) 0; #X array vu 256 float 0; #X coords 0 256 255 0 200 140 1; #X restore 442 208 graph; #X obj 913 90 f; #X obj 959 90 + 1; #X obj 913 119 mod 256; #X msg 913 33 40; #X msg 952 34 0; #X obj 913 61 metro; #N canvas 0 0 512 223 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 43 pd tobin; #N canvas 0 0 543 205 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 32 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 50 91 pd tobin; #N canvas 0 0 587 245 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 32 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 171 pd tobin; #X obj 31 138 xor; #X text 575 30 Start to see xor effect on linear ramp ->; #X text 289 87 <- 1 set this numberbox; #X text 289 44 <- 2 set that numberbox; #X text 31 3 XOR does bitwise xor intersection of two 16 bit integers ; #X text 328 196 XOR:; #X text 299 229 1 xor 1 = 0; #X text 299 259 0 xor 0 = 0; #X text 299 289 1 xor 0 = 1; #X text 299 319 0 xor 1 = 1; #X text 26 339 Steffen Leve Poulsen 2007; #X text 27 359 steffen at menneske dot dk; #N canvas 0 0 587 245 tobin 0; #X obj 417 44 & 1; #X obj 377 44 & 2; #X obj 337 44 & 4; #X obj 297 44 & 8; #X floatatom 269 103 5 0 0 0 - - -; #X obj 247 44 & 16; #X obj 200 44 & 32; #X obj 157 44 & 64; #X obj 107 44 & 128; #X obj 104 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 128; #X obj 124 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 64; #X obj 144 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 32; #X obj 164 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 16; #X obj 184 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 8; #X obj 204 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 4 4; #X obj 224 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 2 2; #X obj 244 104 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 269 134 outlet; #X obj 343 102 inlet; #X connect 0 0 16 0; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 3 0 13 0; #X connect 4 0 2 0; #X connect 4 0 3 0; #X connect 4 0 1 0; #X connect 4 0 0 0; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 4 0 7 0; #X connect 4 0 8 0; #X connect 4 0 17 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 10 0; #X connect 8 0 9 0; #X connect 18 0 4 0; #X coords 0 -1 1 1 222 23 2 100 100; #X restore 31 241 pd tobin; #X obj 753 397 xor; #X obj 31 208 xor; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 1 1 3 1; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 3 0 5 0; #X connect 4 0 3 1; #X connect 5 0 30 0; #X connect 5 1 6 1; #X connect 8 0 10 0; #X connect 9 0 8 1; #X connect 10 0 9 0; #X connect 10 0 2 0; #X connect 10 0 30 1; #X connect 11 0 13 0; #X connect 11 0 13 1; #X connect 12 0 13 0; #X connect 13 0 8 0; #X connect 14 0 17 0; #X connect 15 0 17 1; #X connect 15 0 31 1; #X connect 16 0 31 0; #X connect 17 0 16 0; #X connect 30 0 6 0; #X connect 31 0 29 0;
#N canvas 300 28 801 741 12; #X obj 87 4 inlet; #X obj 263 619 outlet; #X obj 147 227 until; #X msg 147 168 16; #X obj 147 194 t f b; #X msg 282 214 0; #X obj 147 259 f; #X obj 181 260 + 1; #X obj 298 576 f; #X obj 263 575 +; #X obj 199 457 pow; #X msg 199 429 2 $1; #X obj 143 392 f; #X obj 103 392 f; #X obj 103 555 *; #X obj 103 488 &; #X obj 143 488 &; #X obj 148 287 t b b f; #X obj 103 525 !=; #X obj 162 352 inlet; #X obj 87 128 t b f; #X text 272 69 XOR does bitwise xor intersection of two 16 bit integers ; #X text 458 136 XOR:; #X text 429 169 1 xor 1 = 0; #X text 429 199 0 xor 0 = 0; #X text 429 229 1 xor 0 = 1; #X text 429 259 0 xor 1 = 1; #X text 106 669 Steffen Leve Poulsen 2007; #X text 107 689 steffen at menneske dot dk; #X connect 0 0 20 0; #X connect 2 0 6 0; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 4 1 5 0; #X connect 5 0 6 1; #X connect 5 0 9 1; #X connect 6 0 7 0; #X connect 6 0 17 0; #X connect 7 0 6 1; #X connect 8 0 9 1; #X connect 9 0 8 0; #X connect 9 0 1 0; #X connect 10 0 16 1; #X connect 10 0 15 1; #X connect 10 0 14 1; #X connect 11 0 10 0; #X connect 12 0 16 0; #X connect 13 0 15 0; #X connect 14 0 9 0; #X connect 15 0 18 0; #X connect 16 0 18 1; #X connect 17 0 13 0; #X connect 17 1 12 0; #X connect 17 2 11 0; #X connect 18 0 14 0; #X connect 19 0 12 1; #X connect 20 0 3 0; #X connect 20 1 13 1;
-
Chris McCormick -
David Powers -
IOhannes m zmoelnig -
Kyle Klipowicz -
Martin Peach -
padawan12 -
Steffen -
Steffen Leve Poulsen