Re: [PD] cat /boot/vmlinuz-2.6.35-30-generic /dev/dsp ?
Check out /proc/kcore also, this is the current contents of your entire memory ;) -- Regards, buZz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cat /boot/vmlinuz-2.6.35-30-generic /dev/dsp ?
now I remember I tried with a max json preset file (attached), it
produced at amazing rythmic pattern, something like a heavy metal
gimmick. Maybe it can help finding interresting text files.
routing_destination:
routing_line:
scale:
$VAR1 = {
'1' = {
'servo' = {
'6' = {
'routing_line' = 2,
'routing_destination' = 2
},
'1' = {
'scale_min' = 41,
'routing_line' = 1,
'routing_destination' = 1,
'scale_max' = 41
},
'4' = {
'scale_min' = 33,
'routing_line' = 0,
'routing_destination' = 0,
'scale_max' = 33
},
'3' = {
'routing_line' = 3,
'routing_destination' = 3
},
'0' = {
'scale_min' = 0,
'routing_line' = 0,
'routing_destination' = 0,
'scale_max' = 0
},
'7' = {
'routing_line' = 3,
'routing_destination' = 3
},
'2' = {
'routing_line' = 2,
'routing_destination' = 2
},
'5' = {
'routing_line' = 1,
'routing_destination' = 1
}
}
}
};
multiplicator: 0, 0, 0, 0, 0, 0, 0, 0,
tablea:
393939390006578707170707070707745270066000
tableb:
00059900104091009567000
tablec:
3300645200117001060190090
tabled:
Re: [PD] pduino rewrite
Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! #N canvas 490 1631 331 170 10; #N canvas 571 1511 538 392 digital 0; #X obj 58 3 inlet; #X obj 58 286 outlet; #X msg 58 113 0 \$1; #X msg 96 113 1 \$1; #X msg 134 113 2 \$1; #X msg 172 113 3 \$1; #X msg 210 113 4 \$1; #X msg 248 113 5 \$1; #X msg 286 113 6 \$1; #X msg 328 113 7 \$1; #X obj 58 208 +; #X obj 394 106 15; #X msg 58 261 digital \$1 \$2; #X obj 394 127 * 8; #X obj 58 230 pack float float; #X obj 58 163 unpack float float; #N canvas 0 69 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X obj 32 186 change; #X obj 82 187 change; #X obj 132 187 change; #X obj 182 187 change; #X obj 232 188 change; #X obj 282 189 change; #X obj 332 189 change; #X obj 382 189 change; #X connect 0 0 25 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 26 0; #X connect 19 0 27 0; #X connect 20 0 28 0; #X connect 21 0 29 0; #X connect 22 0 30 0; #X connect 23 0 31 0; #X connect 24 0 32 0; #X connect 25 0 8 0; #X connect 26 0 9
Re: [PD] pdtest - pd functional testing external
I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. L-P ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Sorry to interrupt, but just for curiosity's sake, what do you guys mean by testing? Pierre 2011/9/14 Louis-Philippe defa...@spiralix.org I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. L-P ___ 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
Re: [PD] http://puredata.info ?
Yeah, I'm seeing the same and haven't heard anything. .hc On Wed, 2011-09-14 at 06:59 +0200, Björn Eriksson wrote: Hello, sorry if this question already has been raised (just re-subscribed me to the list after some years absence). What is the status of http://puredata.info ? The pages seems to be down at least since last weekend. All the best, Björn Eriksson ___ 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
Re: [PD] pdtest - pd functional testing external
On Wed, 2011-09-14 at 08:13 -0400, Louis-Philippe wrote: I tried to use this on Ubuntu/Maverick 10.10. It built find, but when I loaded the help patch I got: /media/share/code/lp/pdtest/pdtest.pd_linux: /media/share/code/lp/pdtest/pdtest.pd_linux: undefined symbol: lua_getfield pdtest l s f b ... couldn't create maybe a problem linking with liblua... I will look more closely at the build steps for linux when I get some time... About the design, is this just meant to test compiled externals, or do you see it as testing abstractions too? .hc I believe abstractions could be tested too, pdtest main limitation now is to only output and understand lists, symbols and floats but no signals. As a matter of fact, I don't see clearly how signals could be tested. Signals are quite easy to test within Pd. I think it could make sense to keep the management of the tests in Lua, but keep the tests as Pd patches. That way they'll be easier for Pd people to write tests since they would just be patches, and you can more easily test Pd-ish things. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Wed, 2011-09-14 at 11:48 +0200, Ingo wrote: Hi Roman, thanks for taking the time looking at the code. Unfortunately your version will be sending even many more wrong numbers. I have put some list messages into your patch. Keep clicking onto them randomly and you will see that the headers change between 6, 7, 14 and 15. Sometimes they are correct - sometimes not. The problem is due to the change object inside the debyte object. Leaving it out would always send all 8 bits for the group of pins. Leaving it in will keep holding old values. Gotcha. I removed the [change] objects from the [pd debytemask] subpatch. And I also agree, that it would be ugly, if digital pins fire without changing their state. I cannot see any way other than using individual debyte objects for each group unless you would come up with something completely different like storing everything into an array and sending from there (after checking what has changed) which would be much more complicated. Actually, I found the table based approach not that complicated and I think it is more scalable (it covers all possible 16 groups). I added a [pd polychange] subpatch that does exactly what you describe. I hopefully tested it more thoroughly this time. See attached patch. Cheers Roman #N canvas 0 53 450 300 10; #N canvas 179 119 538 392 digital 0; #X obj 42 17 inlet; #X obj 42 334 outlet; #X msg 42 120 0 \$1; #X msg 80 120 1 \$1; #X msg 118 120 2 \$1; #X msg 156 120 3 \$1; #X msg 194 120 4 \$1; #X msg 232 120 5 \$1; #X msg 270 120 6 \$1; #X msg 312 120 7 \$1; #X obj 42 215 +; #X obj 378 113 15; #X msg 42 310 digital \$1 \$2; #X obj 378 134 * 8; #X obj 42 237 pack float float; #X obj 42 170 unpack float float; #N canvas 289 142 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X connect 0 0 8 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 9 0; #X connect 19 0 10 0; #X connect 20 0 11 0; #X connect 21 0 12 0; #X connect 22 0 13 0; #X connect 23 0 14 0; #X connect 24 0 15 0; #X restore 42 85 pd debytemask; #X obj 42 38 t a a; #X msg 69 60 \$1; #X msg 42 60 \$2; #N canvas 315 128 443 301 polychange 0; #X obj 23 20 inlet; #X obj 23 242 outlet; #X obj 236 12 table \$0.digital.in.cache 128; #X obj 23 87 tabread \$0.digital.in.cache; #X obj 23 64 unpack f f; #X obj 23 109 !=; #X obj 23 131 sel 1; #X obj 23 42 t a a; #X obj 23 153 list append; #X obj 83 242 tabwrite \$0.digital.in.cache; #X obj 23 175 t a a a; #X msg 248 215 \$1; #X msg 83 213 \$2; #X connect 0 0 7 0; #X connect 3 0 5 0; #X connect 4 0 3 0; #X connect 4 1 5 1; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 4 0; #X connect 7 1 8 1; #X connect 8 0 10 0; #X connect 10 0 1 0; #X connect 10 1 12 0; #X connect 10 2 11 0; #X connect 11 0 9 1; #X connect 12 0 9 0; #X restore 42 273 pd polychange; #X connect 0 0 17 0; #X connect 2 0 15 0; #X connect 3 0 15 0; #X connect 4 0 15 0; #X connect 5 0 15 0; #X connect 6 0 15 0; #X connect 7 0 15 0; #X connect 8 0 15 0; #X connect 9 0 15 0; #X connect 10 0 14 0; #X connect 11 0 13 0; #X connect 12 0 1 0; #X connect 13 0 10 1; #X connect 14 0 20 0; #X connect 15 0 10 0; #X connect 15 1 14 1; #X connect 16 0 2 0; #X connect 16 1 3 0; #X connect 16 2 4 0; #X connect 16 3 5 0; #X connect 16 4 6 0; #X connect 16 5 7 0; #X connect 16 6 8 0; #X connect 16 7 9 0; #X connect 17 0 19 0; #X connect 17 1 18 0; #X connect 18 0 11 0; #X connect 19 0 16 0; #X connect 20 0 12 0; #X restore 7 13 pd digital messages roman; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] puredata website?
hello, is working the website http://puredata.info/ ?? thanks Andrés Ferrari G. http://www.myspace.com/anfex___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Le 2011-09-14 à 10:47:00, Hans-Christoph Steiner a écrit : Signals are quite easy to test within Pd. I think it could make sense to keep the management of the tests in Lua, but keep the tests as Pd patches. That way they'll be easier for Pd people to write tests since they would just be patches, and you can more easily test Pd-ish things. It also makes sense to keep the management of tests in Pd, and to keep the tests in Pd. That way, it'll be easier for Pd people to modify the test framework to better suit tests. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
You two guys are tough to follow ;) anyway, I'm more a code person than a patch person, and I believe I am not alone, so this is why pdtest has a Lua code core. I totally see your point that tests are better to be implemented in way the external is to be used, i.e. within pd, but I think code still allows this by only being the test dataset emiter and receiver, and has the advantage to have readable code input being close to specifications and a test output log that tells you if it flies or not at a quick glance. Still, pdtest alway need to work inside a test patch adapted to the problem at hand, as what it does is only to output messages and pair them with expected messages to be received back. 2011/9/14 Mathieu Bouchard ma...@artengine.ca Le 2011-09-14 à 10:47:00, Hans-Christoph Steiner a écrit : Signals are quite easy to test within Pd. I think it could make sense to keep the management of the tests in Lua, but keep the tests as Pd patches. That way they'll be easier for Pd people to write tests since they would just be patches, and you can more easily test Pd-ish things. It also makes sense to keep the management of tests in Pd, and to keep the tests in Pd. That way, it'll be easier for Pd people to modify the test framework to better suit tests. __**__** ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Le 2011-09-14 à 12:06:00, Louis-Philippe a écrit : You two guys are tough to follow ;) Quoi, est-ce qu'on est pas assez unanimes ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Non, pas vraiment. Mais bon, c'est ça une discussion... Quoi, est-ce qu'on est pas assez unanimes ? anyway, I'll be really happy to have other options when the need arises to test in a different paradigm, but for now I will continue to improve pdtest as it's the working solution I already have, and honestly I don't completely get how you want achieve PureUnity... I'm certainly missing some concepts and experience with pd... it will be fun to understand more as the PureUnity project goes forward. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows
Where should I save the file? Pierre 2011/9/14 Hans-Christoph Steiner h...@at.or.at I made a quick plugin that lets you cycle thru the open windows in Pd using Ctrl/Cmd- and Ctrl/Cmd-. It's attached, it should work on all platforms. .hc ___ 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
Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows
how about a plugin that lets you see the tree of windows, just as when you ctrl-click (or something) on a patch name in max? I made a quick plugin that lets you cycle thru the open windows in Pd using Ctrl/Cmd- and Ctrl/Cmd-. It's attached, it should work on all platforms. .hc -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows
What would be great would be to have an IDE view similar to what Jmax phoenix does, where you have a tree on the left and a single canvas taking up most of the window. I think one could do this with ttk::treeview in tk. Would probably require more than a gui-plugin, though. -Jonathan - Original Message - From: João Pais jmmmp...@googlemail.com To: pd-list@iem.at; Hans-Christoph Steiner h...@at.or.at Cc: Sent: Wednesday, September 14, 2011 1:02 PM Subject: Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows how about a plugin that lets you see the tree of windows, just as when you ctrl-click (or something) on a patch name in max? I made a quick plugin that lets you cycle thru the open windows in Pd using Ctrl/Cmd- and Ctrl/Cmd-. It's attached, it should work on all platforms. .hc --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ 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
Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows
Same as installing an external: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files .hc On Wed, 2011-09-14 at 18:45 +0200, Pierre Massat wrote: Where should I save the file? Pierre 2011/9/14 Hans-Christoph Steiner h...@at.or.at I made a quick plugin that lets you cycle thru the open windows in Pd using Ctrl/Cmd- and Ctrl/Cmd-. It's attached, it should work on all platforms. .hc ___ 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
Re: [PD] new plugin: Ctrl- and Ctrl- for cycling thru windows
Have you tried any of the category browser plugins? They add it to the right-click menu, here's one: https://github.com/pd-starterkit/right-click-menu .hc On Wed, 2011-09-14 at 19:02 +0200, João Pais wrote: how about a plugin that lets you see the tree of windows, just as when you ctrl-click (or something) on a patch name in max? I made a quick plugin that lets you cycle thru the open windows in Pd using Ctrl/Cmd- and Ctrl/Cmd-. It's attached, it should work on all platforms. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdtest - pd functional testing external
Yeah, its worthwhile to implement it the way that is useful for you. But I think you'll find that if you implement the tests as patches, and then have the whole loading, running, and comparing framework in Lua, it'll be easier to do. As for testing signals in lua space, one way would be to have the test program just write blocks of samples and then read them back, then compare them. That's what pd is doing in DSP. .hc On Wed, 2011-09-14 at 12:06 -0400, Louis-Philippe wrote: You two guys are tough to follow ;) anyway, I'm more a code person than a patch person, and I believe I am not alone, so this is why pdtest has a Lua code core. I totally see your point that tests are better to be implemented in way the external is to be used, i.e. within pd, but I think code still allows this by only being the test dataset emiter and receiver, and has the advantage to have readable code input being close to specifications and a test output log that tells you if it flies or not at a quick glance. Still, pdtest alway need to work inside a test patch adapted to the problem at hand, as what it does is only to output messages and pair them with expected messages to be received back. 2011/9/14 Mathieu Bouchard ma...@artengine.ca Le 2011-09-14 à 10:47:00, Hans-Christoph Steiner a écrit : Signals are quite easy to test within Pd. I think it could make sense to keep the management of the tests in Lua, but keep the tests as Pd patches. That way they'll be easier for Pd people to write tests since they would just be patches, and you can more easily test Pd-ish things. It also makes sense to keep the management of tests in Pd, and to keep the tests in Pd. That way, it'll be easier for Pd people to modify the test framework to better suit tests. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! ___ 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] Selecting random wavefile from folder without knowing the names
Hi, how can i select a random wavefile from a folder withouth knowing the names of the files in my folder? how can i read all the files names in a folder and then select one? which would be the best way of doing this? thanks A. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Selecting random wavefile from folder without knowing the names
Le 2011-09-14 à 22:14:00, adam sanches a écrit : Hi, how can i select a random wavefile from a folder withouth knowing the names of the files in my folder? how can i read all the files names in a folder and then select one? which would be the best way of doing this? [hcs/folder_list] then [list length] then [random] then [list split] then $1. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
