Wow, I just compared your version of [pd digital message] with mine and
yours takes only 180ms to process 100 of messages, while mine uses
over 8s.
Frankly, I wouldn't have expected such a big difference Let me dig
into this.
Roman
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote:
The
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote:
The [change -1] is a great idea, I just committed that to bytemask.pd
and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem
quite labor-intensive, but they work. I think it would work better to
use multiple instances of
On Fri, 2011-09-16 at 11:32 +0200, Roman Haefeli wrote:
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote:
The [change -1] is a great idea, I just committed that to bytemask.pd
and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem
quite labor-intensive, but they work. I think
Wow, I just compared your version of [pd digital message] with mine and
yours takes only 180ms to process 100 of messages, while mine uses
over 8s.
Frankly, I wouldn't have expected such a big difference Let me dig
into this.
Roman
That's more than I would have expected, too!
I
Hi Roman,
Frankly, I'm not yet convinced that those little improvements in
[arduino] will significantly improve the overall Pd performance.
Here's the reason why I started really to simplify any patch, no matter if
audio or control objects:
I have been programming for about 4 years on one
To make sure boards that are larger than 56 digital in pins you should copy
a couple more of these objects to go up to 128. Of course since [] and []
seems to be slightly faster that would be the choice.
To be even more efficient the object [pd route digital/analog] should be
bypassed by adding
Hi Ingo,
On 16/09/11 13:02, Ingo wrote:
When I started I thought it was very convenient to use wireless
[send/receive] objects to send midi data to the sample-voices (which it is).
[snip]
Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million
times per second that the
Hi Claude,
When I started I thought it was very convenient to use wireless
[send/receive] objects to send midi data to the sample-voices (which it
is).
[snip]
Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million
times per second that the individual [receive] objects
Nachricht-
Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
Ingo
Gesendet: Freitag, 16. September 2011 16:42
An: 'Claude Heiland-Allen'; pd-list@iem.at
Betreff: Re: [PD] pduino rewrite
Hi Claude,
When I started I thought it was very convenient to use
[mailto:pd-list-boun...@iem.at] Im Auftrag von
Hans-Christoph Steiner
Gesendet: Mittwoch, 14. September 2011 22:33
An: Roman Haefeli
Cc: pd-list@iem.at
Betreff: Re: [PD] pduino rewrite
As Ingo pointed out, one bug is that [mapping/debytemask] has the
[change] object for each outlet. So
Hans-Christoph Steiner
Gesendet: Mittwoch, 14. September 2011 22:33
An: Roman Haefeli
Cc: pd-list@iem.at
Betreff: 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
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote:
The reason why I didn't make an abstraction for the debyte is that I
wanted to keep the number of files and dependencies as low as possible. I
think this was the original idea of the rewrite, right?
Yeah, exactly. I would like to be able to
Interesting. How did you quantify the amount of message transfers? What
makes it differ so much, like you say?
I simply (roughly) counted the numbers of objects the calculation including
all sub processes have to pass until you get the final result.
(Unfortunately I cannot tell how heavy each
On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote:
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote:
The reason why I didn't make an abstraction for the debyte is that I
wanted to keep the number of files and dependencies as low as possible. I
think this was the original idea of the
On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote:
Interesting. How did you quantify the amount of message transfers? What
makes it differ so much, like you say?
I simply (roughly) counted the numbers of objects the calculation including
all sub processes have to pass until you get the final
On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote:
On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote:
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote:
The reason why I didn't make an abstraction for the debyte is that I
wanted to keep the number of files and dependencies
Hi Hans,
unfortunately I am not really good at C or C++ so I have to stick with
simplifying within Pd until I get there. But I am actually working on it so
I'll be able to replace certain objects in my patches by more efficient
externals. Anyway, I think in the case of simplifying the pduino
On Thu, 2011-09-15 at 18:43 +0200, Roman Haefeli wrote:
On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote:
On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote:
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote:
The reason why I didn't make an abstraction for the debyte is
On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote:
Hi Hans,
unfortunately I am not really good at C or C++ so I have to stick with
simplifying within Pd until I get there. But I am actually working on it so
I'll be able to replace certain objects in my patches by more efficient
externals.
On Thu, 2011-09-15 at 13:29 -0400, Hans-Christoph Steiner wrote:
On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote:
Hi Hans,
unfortunately I am not really good at C or C++ so I have to stick with
simplifying within Pd until I get there. But I am actually working on it so
I'll be able to
The [change -1] is a great idea, I just committed that to bytemask.pd
and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem
quite labor-intensive, but they work. I think it would work better to
use multiple instances of [debytemask].
.hc
Not sure what you mean by
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
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
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
crazy now sending wrong stuff all over the place.
Ingo
-Ursprüngliche Nachricht-
Von: Hans-Christoph Steiner [mailto:h...@at.or.at]
Gesendet: Freitag, 9. September 2011 16:41
An: Ingo
Cc: 'Roman Haefeli'; 'pd-list'
Betreff: Re: [PD] pduino rewrite
I basically haven't used
Hi Roman, Olsen and Hans,
Here' a replacement object that fixes the behaviour that wrong digital in
pins get recognized when more than the first 6 pins are used. I hope there
is nothing else interfering with those pins anymore.
The object digital_messages inside the patch should be placed here
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
Hi Ingo
On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote:
OK, I got it!
Downloading the files didn't work (at least not on my Windows computer) but
copying the content into a bunch of text files and renaming them did.
Hm.. is this probably due to Windows and Linux using different line
breaks
Hi Roman,
I just messed around with the rewrite and - as you mentioned - you didn't
fix any of the bugs.
I even think I send you a mail about the digital pins 2 3 and provided a
fix for it here at the forum. Of course it's still there!
About the other things:
- The test patch has still no
I forgot to mention: I tested with a Duemilanove.
Ingo
-Ursprüngliche Nachricht-
Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
Ingo
Gesendet: Freitag, 9. September 2011 10:04
An: 'Roman Haefeli'; 'olsen'; 'pd-list'
Betreff: Re: [PD] pduino rewrite
Hi
On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote:
Hi Roman,
I just messed around with the rewrite and - as you mentioned - you didn't
fix any of the bugs.
I even think I send you a mail about the digital pins 2 3 and provided a
fix for it here at the forum. Of course it's still there!
I did test it with the Duemilanove. But I also tested Diecimila and Uno.
To me the problem looks like unfortunate design in the firmata. The
buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a
bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I
mentioned
I basically haven't used an Arduino in 2 years, so I am a poor candidate
for debugging this stuff. Roman and Olsen are much better candidates
for this job.
The digital input pins are reported using the hardware-level ports, the
hardware is organized around pins 0-7 being one port, 8-15,
I could not open any patch at all! Neither Natty nor Windows XP worked.
I am still on Pd-extended 0.42.5.
There is a huge list of stuff (not pd library related) missing.
So far this doesn't look like it's improving any dependency problem.
Ingo
buenas tutti
roman me did some rewrite on the
are gone.
Ingo
Betreff: Re: [PD] pduino rewrite
I could not open any patch at all! Neither Natty nor Windows XP worked.
I am still on Pd-extended 0.42.5.
There is a huge list of stuff (not pd library related) missing.
So far this doesn't look like it's improving any dependency problem.
Ingo
This is a great start, it needed some loving. I'll check it out when I
have some time.
.hc
On Fri, 2011-09-02 at 12:20 +0200, olsen wrote:
buenas tutti
roman me did some rewrite on the pduino - citing the README:
Pduino - improved
-
All Pd patches are based on the
36 matches
Mail list logo
