Re: [PD] Installing PD on OpenSUSE
On 2014-05-11 12:45, Andrew Faraday wrote: Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... The latest code should compile for Lua5.2 as well as 5.1, do you have this version of the pdlua makefile?: http://sourceforge.net/p/pure-data/svn/17235/ Martin you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ 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] Installing PD on OpenSUSE
I removed the requirement for 5.1 in the makkefile, this was in January of this year. I don't know when the pd-extended externals source was last updated from svn, maybe it needs refreshing. From the diff: - LUACFLAGS += -I/usr/include/lua5.1 # lua is named differently on every platform, check this and change it to fit - LIBS += -llua5.1 # lua is named differently on every platform, check this and change it to fit + LUACFLAGS += -I/usr/include/lua # lua is named differently on every platform, check this and change it to fit + LIBS += -llua # lua is named differently on every platform, check this and change it to fit Also there are some changes in pdlua.c to accommodate the new API in lua5.2, as seen here: http://sourceforge.net/p/pure-data/svn/17235 Martin On 2014-05-11 13:26, Andrew Faraday wrote: I was under the impression that I had the latest code, I built it using Pd-extended_0.43.4-source.tar.bz2 line 152 is: LUACFLAGS += -I/usr/include/lua5.1 Also dependencies seem very sparsely documented, could I be missing one? Andrew F Date: Sun, 11 May 2014 13:13:09 -0400 From: martin.pe...@sympatico.ca To: jbtur...@hotmail.com; pd-list@iem.at Subject: Re: [PD] Installing PD on OpenSUSE On 2014-05-11 12:45, Andrew Faraday wrote: Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... The latest code should compile for Lua5.2 as well as 5.1, do you have this version of the pdlua makefile?: http://sourceforge.net/p/pure-data/svn/17235/ Martin you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ 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
Re: [PD] How to read I2C sensors?
On 2014-04-27 13:52, Ingo wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. If the machine Pd is running on has an I2C port and is running linux then you can use spidev to access it. Otherwise you need to use a serial connection to an off-board microcontroller like the arduino or teensy or FRDM-KL25Z to relay messages between the I2C and USB serial connections. A lot of motherboards have I2C but it's mainly used for the temperature sensors and you don't get access via any header. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ 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
Re: [PD] [PD-dev] oggread~ not working on pd-extended or libpd on windows.
I think vanilla is compiled with MSVC and extended with MinGW so there
are incompatibilities in the c runtime especially where file pointers
are concerned. Sometimes externals will work on both versions but if the
external opens its own files using Pd functions to find the path then it
probably won't.
Martin
On 2014-04-05 11:36, Rafael Vega wrote:
I also find it strange that using the external on pd-vanilla by copying
the dll to the extra folder in the vanilla directory works fine. Any
ideas why? Maybe has something to do with compiler environment
differences between vanilla and extended? Do you guys use MinGW for both?
On Sat, Apr 5, 2014 at 10:34 AM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Hi Miller,
On my windows machines (XP and 8.1), if I tried to open with mode
'r', the later call to ov_open would fail. If I change the mode to
'rb', the later call to ov_open works fine. I also read somewhere
that the 'b' mode does nothing on Unix (I still have to test that
when I'm back to my Linux and Mac machines).
As for the comparison against NULL, the original code was comparing
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
And I changed it to = instead. You are right in that it makes no
sense to compare the sign of a pointer so == it is :)
R.
On Sat, Apr 5, 2014 at 9:03 AM, Miller Puckette m...@ucsd.edu
mailto:m...@ucsd.edu wrote:
I THink it should really be:
if((x-x_file = sys_fopen(filename-s_name, r)) == 0)
sys_fopen returns NULL (also known as 0) on failure, otherwise a
pointer;
it makes no sense to check the sign of a pointer as far as I know.
cheers
Miller
On Fri, Apr 04, 2014 at 11:21:37PM -0400, Martin Peach wrote:
I think it's here:
http://sourceforge.net/p/pure-data/patches/
Martin
On 2014-04-04 21:49, Rafael Vega wrote:
Even more stuff ;)
In the same file, oggread~.c there is a line that reads:
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
But it should be:
if((x-x_file = sys_fopen(filename-s_name, rb)) = 0)
Now, to figure out how to submit a patch to pd-extended :P
On Fri, Apr 4, 2014 at 7:22 PM, Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
mailto:email.r...@gmail.com mailto:email.r...@gmail.com
wrote:
Follow up:
Looking at the code for oggread~, I found that it does
the actual
opening of the file with
if(ov_open(x-x_file, x-x_ov, NULL, -1) 0)
on the ov_open documentation it warns windows
programmers not to use
ov_open but ov_open_callbacks instead [1] and [2] so I
changed that
line to the following and I'm getting the message
Bitstream does
not contain any Vorbis data. I'm pretty sure my file is
a valid ogg
file. I created it using audacity and also tried with an
ogg file
downloaded from freesound.org http://freesound.org
http://freesound.org.
Any help with this will be very much appreciated
:)
int ret = ov_open_callbacks(x-x_file,
x-x_ov, NULL, -1,
OV_CALLBACKS_DEFAULT);
switch(ret){
case OV_EREAD:
post(A read from media returned an
error.);
break;
case OV_ENOTVORBIS:
post(Bitstream does not contain any
Vorbis data);
break;
case OV_EVERSION:
post(OV_EVERSION - Vorbis version
mismatch.);
break;
case OV_EBADHEADER:
post(Invalid Vorbis bitstream header.);
break;
case OV_EFAULT:
post(Internal logic fault; indicates a
bug or
heap/stack corruption.);
break;
}
if(ret 0)
links:
[1]
http://xiph.org/vorbis/doc/vorbisfile/ov_open_callbacks.html
[2] http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
On Fri, Apr 4, 2014 at 5:48 PM, Rafael Vega
email.r...@gmail.com mailto:email.r
Re: [PD] [PD-dev] oggread~ not working on pd-extended or libpd on windows.
I think it's here:
http://sourceforge.net/p/pure-data/patches/
Martin
On 2014-04-04 21:49, Rafael Vega wrote:
Even more stuff ;)
In the same file, oggread~.c there is a line that reads:
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
But it should be:
if((x-x_file = sys_fopen(filename-s_name, rb)) = 0)
Now, to figure out how to submit a patch to pd-extended :P
On Fri, Apr 4, 2014 at 7:22 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Follow up:
Looking at the code for oggread~, I found that it does the actual
opening of the file with
if(ov_open(x-x_file, x-x_ov, NULL, -1) 0)
on the ov_open documentation it warns windows programmers not to use
ov_open but ov_open_callbacks instead [1] and [2] so I changed that
line to the following and I'm getting the message Bitstream does
not contain any Vorbis data. I'm pretty sure my file is a valid ogg
file. I created it using audacity and also tried with an ogg file
downloaded from freesound.org http://freesound.org.
Any help with this will be very much appreciated
:)
int ret = ov_open_callbacks(x-x_file, x-x_ov, NULL, -1,
OV_CALLBACKS_DEFAULT);
switch(ret){
case OV_EREAD:
post(A read from media returned an error.);
break;
case OV_ENOTVORBIS:
post(Bitstream does not contain any Vorbis data);
break;
case OV_EVERSION:
post(OV_EVERSION - Vorbis version mismatch.);
break;
case OV_EBADHEADER:
post(Invalid Vorbis bitstream header.);
break;
case OV_EFAULT:
post(Internal logic fault; indicates a bug or
heap/stack corruption.);
break;
}
if(ret 0)
links:
[1] http://xiph.org/vorbis/doc/vorbisfile/ov_open_callbacks.html
[2] http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
On Fri, Apr 4, 2014 at 5:48 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Hi.
I am trying to use [oggread~] external on an application i'm
developing with libpd. No problems on mac or linux. Howerver, on
windows (xp and 8, 32bit) I keep getting an error message from
oggread~ when I try to open an ogg file. Even ogg_read~-help.pd
won't work:
oggread~: file C:/Users/rv/any.ogg opened
oggread~: error: could not open C:/Users/rv/Desktop/any.ogg as
an OggVorbis file
oggread~: file closed due to error
I have tried pd-extended (both installer and standalone) and I
also compiled oggread~ into my application and loaded it with
libpd, same outcome.
The weirdest part is that if I run pd vanilla, copy oggread~.dll
from pd-extended into the extra directory, the ogg files are
opened correctly.
Any ideas on how to make this work? What kind of debug info can
I provide?
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
___
Pd-dev mailing list
pd-...@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] arduino/comport load hang
On 2014-02-25 23:11, Allen, Michael wrote: I've had issues getting an arduino to work right with PD on my Raspberry Pi. Basically PD won't start up right with the arduino plugged in from the command line without some finesse. I turn the Pi on, start Jack, then start PD-Extended to open a patch. The patch has a load bang to a comport object with the device name and baud rate. This patch has a the CPU load meter set to print, and the value of several pots set to print through the arduino. The first time the patch will freeze: ... Any ideas why it won't load up from the start? I have tried delaying the comport open for a second, with no luck. Well without seeing the patch, I can only guess: Does the loadbang hit the baud rate or the open first? Make sure you don't send anything to the arduino for a few seconds or you will invoke the bootloader by mistake. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On 2014-02-22 16:54, Pagano, Patrick wrote: Hello i have asked this is a few different ways and experimented but i am wondering, how does one create smooth random numbers that flow between each number instead of hoping from number to number? One way is to do a random walk, where you would start with 64 and then add one if random(128) is greater than 63 or subtract one if it's less. (or add zero for some deadband around 63). You could use a constant sample rate or vary that as well with random delays between samples. Random walks tend to walk outside the range so you also need a way to bring it back when it crosses a boundary (0 or 127). Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach/net iemnet and other way to get file from the net
On 2014-02-12 11:13, Cyrille Henry wrote: hello, We are trying to get small text file from the internet using mrpeach net objects. there is some few crash. gdb backtrace gives : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff8cf81700 (LWP 31771)] 0x7fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 225x-x_addr = ntohl(*(long *)hp-h_addr); (gdb) watchdog: signaling pd... watchdog: signaling pd... bt #0 0x7fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 #1 0x773a8f6e in start_thread (arg=0x7fff8cf81700) at pthread_create.c:311 #2 0x76ecf9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 (this is on ubuntu 13.10 linux 64 bit / pd 0.45 / mrpeach from svn, but osX gives the same kind of crash ) iemnet object are not more stable. there are lot's of thread about this in the list. is there anything new, or something we can do to avoid crash? I don't recall any threads about this kind of crash. It looks like a 64-bit issue. If it really crashes at x-x_addr = ntohl(*(long *)hp-h_addr); then possibly the long type is too long or the h_addr field is not a long in 64-bit or h_addr is not properly initialized, so ntohl() looks in the wrong place and segfaults. I never get any such crashes on 32-bit systems, but so far I haven't tried it on 64-bit. or is there an other solution that would be cross platform (linux, osX, windows) and would allow a patch to download text file from a server? You could probably make a single object with pdlua or pyext that does just that. Martin thanks cheers Cyrille ___ 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] mrpeach/net iemnet and other way to get file from the net
On 2014-02-12 11:51, Martin Peach wrote: It looks like a 64-bit issue. If it really crashes at x-x_addr = ntohl(*(long *)hp-h_addr); then possibly the long type is too long or the h_addr field is not a long in 64-bit or h_addr is not properly initialized, so ntohl() looks in the wrong place and segfaults. I never get any such crashes on 32-bit systems, but so far I haven't tried it on 64-bit. I just committed a change to tcpclient.c in svn that might fix it, changing long to uint32_t to make sure it accesses a 32-bit field. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD - 2] check mail with pd ?
Did you try [pyext gmail.box] | [t b f] | | [bng] [nbx\ ? Martin On 2014-02-09 17:19, Fero Kiraly wrote: I think I have found an interesting theme about strings. ;) but the content of email dont really interest me. I actually need to get a bang when an mail with some subject is found, my pyext extension can find the emails BUt it wont send a bang (maybe bug?) look attached. thanks for any ideas fero ___ 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] [PD - 2] check mail with pd ?
On 2014-02-09 18:39, Fero Kiraly wrote: ) On Feb 10, 2014 12:34 AM, Fero Kiraly fero.kir...@gmail.com mailto:fero.kir...@gmail.com wrote: yes, i tried many combinations of sending / routing message.. everything works besides getting bang from that.. i also trided a simple counter which works but i cant get no bang trigger from any boxes... i have only clue to recompile pyext... because i use the precompiled x64 version from g~ 's site. it is working for you? No I have never been able to get [pyext] to compile. I would usually put a [print] on the output to see what it really is outputting and go from there. Martin On Feb 10, 2014 12:09 AM, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: Did you try [pyext gmail.box] | [t b f] | | [bng] [nbx\ ? Martin On 2014-02-09 17:19, Fero Kiraly wrote: I think I have found an interesting theme about strings. ;) but the content of email dont really interest me. I actually need to get a bang when an mail with some subject is found, my pyext extension can find the emails BUt it wont send a bang (maybe bug?) look attached. thanks for any ideas fero ___ Pd-list@iem.at mailto: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
Re: [PD] check mail with pd ?
A few years ago I implemented a patch for strings in Pd that adds a
string or blob type that allows (I think) for what you are describing. I
believe it's still part of Pd extended, but Miller didn't like it for
some reason.
I prefer to manipulate strings in a another language as it just seems
like a lot of work to make it happen with boxes and wires when you can
just call string functions in a high level language.
Kind of like building a Turing machine holes-in-paper-tape version of a
program, it can be an interesting exercise but practically it's useless.
Martin
On 2014-02-08 03:14, Jonathan Wilkes wrote:
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm. But
it's irrelevant to getting decent string manipulation within Pd, meaning
using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string hello{world}
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string hello{world}
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
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] OSC server to many clients
On 2014-02-02 11:37, Atte wrote: Hi Basic OSC confusion here: I'd like to run a server that keeps track of time and shares that to a number of clients, each of which run on their own, but with access to this common, global time. However all the examples I found with [sendOSC] or [tcpsend] suggests that the sender connects to *one* client, which isn't what I want. I'd rather like to have the server broadcast to any number of clients that can pick up this information if they like. Have I got OSC all wrong? How to best achieve what I need? It's not really OSC, more the transport layer. With [udpsend] you can broadcast or send to a multicast address (http://en.wikipedia.org/wiki/Multicast_address). Multicasting may be more efficient as it only sends to clients that connected to the multicast address. Broadcasts go to every machine on the subnet. Multicasting is usually more of a pain to get working. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] relative paths with mrpeach [midifile] in abstraction
On 2014-01-25 03:10, Dan Wilcox wrote: Is there some way to modify mrpeach [midifile] so that it will correctly handle relative paths while it's in an abstraction? I notice that soundfiler does this. I could probably do that by copying the way [soundfiler] does it. I need to look at the code. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] read first bytes of a file with [binfile]
On 2014-01-25 12:03, Jack wrote:
It looks like that is not possible.
Would it be doable to add that feature to [binfile] because I need to
read the first bytes of files 3 Gigabytes ?
For example a message like
[read file.ext 200{
|
[binfile]
would read only the first 200 bytes? That should be doable.
Martin
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal math explanation
On 2014-01-18 12:49, IOhannes m zmölnig wrote: On 01/18/2014 06:24 PM, Pall Thayer wrote: Can anyone tell me what one is accomplishing when doing something like this: [osc~ 440] | [+~] |\ x1 [+~] |\ x2 [+~] |\ x3 [+~] x4 ... so you could write the patch as: [osc~ 440] | [*~ 8] more often you see [*~] instead of [+~], which is a simple way to square the input. Of course squaring the input like [osc~] | | [*~] also doubles its frequency. It makes an interesting kind of noise too if you do [noise~] | | [*~] ...not sure what colour of noise that is, blue? It seems to have more high frequency content than white noise. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
On 2013-12-31 19:32, Chris Clepper wrote: It's very, very easy to avoid any sort of clipping processing by using hardware with drivers that don't have any! Avid, Apogee, MOTU, RME, and many others have bit transparent OSX CoreAudio drivers. Also, any DAC worth it's using can reconstruct far beyond 0dBFS without distortion, so hearing volume increase past -1..1 in software is not surprising. I recall the ADI 1955 and equivalent TI part putting out +12dBFS or something ridiculous, but those ain't Wolfson low power headphone codecs neither! A DAC can only go to 0dBFS by definition. If it appears to go beyond that then something is scaling the input to be less than full scale at full scale. For instance a 24-bit DAC could be sent 16 16-bit full-scale streams and not clip. Only if 16-bits is considered full scale does that make it +12dBFS. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
I can see how a filter circuit following a DAC can swing more than the DAC for example if two successive samples are full-scale, but there's no way a DAC can output beyond its own full scale except momentarily while it's settling to a value inside its range. The scaling has to be done before the DAC. You just can't reconstruct a clipped signal unless the clipping is very mild or the signal is very simple, like a sine wave. What if the signal is +12dBFS white noise? I meant that if you take 16 bits to be full-scale but you have a 24-bit DAC you _could_ use the 16 LSBs of the DAC as full scale, then you have a lot of headroom but your signal to noise ratio is not as good, and maybe something like this is happening in the default MacOS headphone driver. Martin On 2014-01-01 13:50, Chris Clepper wrote: Nope, the DAC can freely construct intersample peaks as it sees fit and those can easily exceed 0 dBFS. It has been common practice in the industry for more than a decade to reconstruct clipped samples well above 0 dBFS - partially to make up for shitty mixing and mastering prevalent in music, and also because it's the right way to do it. 16 bits full scale and 24 bits full scale are the same 0dBFS signal. The bits are added at the bottom not the top. On Wed, Jan 1, 2014 at 1:34 PM, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-12-31 19:32, Chris Clepper wrote: It's very, very easy to avoid any sort of clipping processing by using hardware with drivers that don't have any! Avid, Apogee, MOTU, RME, and many others have bit transparent OSX CoreAudio drivers. Also, any DAC worth it's using can reconstruct far beyond 0dBFS without distortion, so hearing volume increase past -1..1 in software is not surprising. I recall the ADI 1955 and equivalent TI part putting out +12dBFS or something ridiculous, but those ain't Wolfson low power headphone codecs neither! A DAC can only go to 0dBFS by definition. If it appears to go beyond that then something is scaling the input to be less than full scale at full scale. For instance a 24-bit DAC could be sent 16 16-bit full-scale streams and not clip. Only if 16-bits is considered full scale does that make it +12dBFS. Martin _ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/__listinfo/pd-list 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
Re: [PD] AM by keeping the Carrier (Not Ring Mod)
On 2013-12-31 06:50, Arda Eden wrote: Hi, Most of the AM examples are simply multiplying carrier and modulator outputs, which is also known as Ring Modulation. But in the resulting spectrum the carrier is gone and only the side bands appear. I couldn’t figure out a way to keep the carrier signal in the resulting spectrum (Like as in real AM, not RM). It was easy in Csound for example, since the amplitude value is an input parameter to the oscil function. Any ideas ? Do it the same way as in analog, add a DC offset to one of the signals. [+~ 0.02] Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
On 2013-12-29 10:08, Alexandre Torres Porres wrote: here's the deal, if I have a square wave in Pd running at 1 -1 peak to peak, then you say that should be my maximum output, right? Thing is that if I give it an extra boost (say, multiply it by 2) I can clearly listen an increase in loudness. Hence, something in my system is allowing some headroom to be output. I got a macbook air from 2010 running 10.7.5... if Pd is not responsible for this, maybe my hardware + Mac OS is? Yes it's a Mac-specific issue. On Win7 I get no difference above 1.0. The Apple audio driver is responsible for clipping values outside of [-1.0..1.0] as they arrive from possibly multiple applications. The docs state that clipping can be done in a soft way, so I suspect that the default driver (for the headphone output) is doing some sort of compression. Possibly if you use an external interface this won't happen (?). (see for example https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/WritingAudioDrivers/ImplementDriver/ImplementDriver.html#//apple_ref/doc/uid/TP3732-BAJCBIAF ) Martin here's the patch, try yourselves and tell me what you get please. Cheers #N canvas 653 26 257 182 10; #X obj 79 97 dac~; #X obj 85 41 square~ 440; #X floatatom 125 72 5 0 0 0 - - -; #X obj 85 70 *~; #X connect 1 0 3 0; #X connect 2 0 3 1; #X connect 3 0 0 0; #X connect 3 0 0 1; 2013/12/21, IOhannes m zmölnig zmoel...@iem.at: On 2013-12-21 14:58, peiman khosravi wrote: However, it's probably wise to clip the signal before sending it to dac~. Entirely for health and safety reasons! this really depends...a clipping sine will have loads of high frequencies that might be equally damaging to your audience. if you want to be safe, use math to make sure that your signal won't exceed -1..+1 before sending to the [dac~]. or use a limiter (zexy has a handy one). fgmrdsa IOhannes ___ 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] headroom in Pd
On 2013-12-20 16:55, Alexandre Torres Porres wrote: Hi there, where can I find info about headroom and clipping on Pd. Or can anyone tell me quickly how it goes? Does it always really clip over a maximum of 1, or is there some headroom? Does it depend on the audiocard or something? The soundcard will always clip above +1 and below -1, and sometimes even within those limits (if the interpolated waveform between samples goes over the limit). Pd will not clip internally, so you can calculate with larger numbers as long as you scale them back down before listening to them. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ordering stream
On 2013-12-12 07:41, David Welch wrote: say I have a stream of ASCII numbers coming in from an Arduino device. It contains a letter indicating the beginning of the stream, something like (when you translate from ASCII): B 1023 1022 1021 1023 1021 etc. Does anyone know how one can process this in such a way that the numbers are handled in the same order, correctly? One way is to have a counter that resets with the 'B' character. Use [pack 0 0] to prefix the count to each received character and then use [route 0 1 2 3...] to extract the characters at the correct position. This doesn't work if the 'B' character can be part of the list. A more robust solution is to use SLIP to encode the packets in the Arduino and [slipdec] from pd-extended to decode them. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Connect Bluetooth devices
I don't know how bluetooth works on linux but on Windows and Mac you get a list of serial ports for bluetooth that exist even when no bluetooth device is associated with them. Maybe if you are not actually using the port it will show up? Martin On 2013-11-26 05:51, sebaroc...@gmail.com wrote: Thanks for your answer Martin. When i create comport object i receive this error: [comport] ** ERROR ** could not get termios-structure of device /dev/ttyS0 [comport] opening serial port 0 failed! I connected my phone using bluetooth, started transferring a file and in that moment sent the [devices] message to comport, what i got in the console was: /[comport]: available serial ports:/ Any ideas? I just need to detect the bluetooth device and get the signal strength... Thanks you!! 2013/11/25 Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca If you send a [devices( message to [comport] it will print a list of available ports in the console. If your bluetooth device is in the list you can open it using the name it has in the list. Martin On 2013-11-25 17:00, sebaroc...@gmail.com mailto:sebaroc...@gmail.com wrote: Hi everybody, I would like to connect my mobile with a pure data patch, my main objective is just get the strength of the signal, ie if the mobile is near the pc or far. Exist any object in pure date in order to achieve this? I was searching and found him and comport objects, but i couldn't manage to make it work. Thanks you! Cheers, Sebastián _ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/__listinfo/pd-list 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] Connect Bluetooth devices
If you send a [devices( message to [comport] it will print a list of available ports in the console. If your bluetooth device is in the list you can open it using the name it has in the list. Martin On 2013-11-25 17:00, sebaroc...@gmail.com wrote: Hi everybody, I would like to connect my mobile with a pure data patch, my main objective is just get the strength of the signal, ie if the mobile is near the pc or far. Exist any object in pure date in order to achieve this? I was searching and found him and comport objects, but i couldn't manage to make it work. Thanks you! Cheers, Sebastián ___ 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] how to install and use GPIO external
The rpi uses arm architecture so you should be building for .l_arm Martin On 2013-11-12 15:00, Ingirafn Steinarsson wrote: Hi, I would like to ask about the compiling. I belived I compiled the code. No warning came up while doing it. I took out the -m32 with the # symbol, like here. # --- LINUX i386 and ia64 --- l_i386: $(NAME).l_i386 l_ia64: $(NAME).l_ia64 .SUFFIXES: .l_i386 .l_ia64 .l_arm LINUXCFLAGS = -DPD -O2 -funroll-loops -fomit-frame-pointer \ -fno-strict-aliasing -Wall -W -Wshadow -Wstrict-prototypes \ -Wno-unused -Wno-parentheses -Wno-switch $(CFLAGS) UNIXINCLUDE = -I../pd/src -I../../pd/src -I../../../pd/src \ -I../../../../pd/src -I../../../../../pd/src LINUXINCLUDE = $(UNIXINCLUDE) #tek ut allan i386 #.c.l_i386: #$(CC) $(LINUXCFLAGS) $(LINUXINCLUDE) -m32 -o $*.o -c $*.c #$(CC) -m32 -shared -o $*.l_i386 $*.o -lc -lm #strip --strip-unneeded $*.l_i386 #rm -f $*.o -- Then when I run the help file I get this error code. /home/pi/pure/pi-externs/gpio/gpio.l_i386: /home/pi/pure/pi-externs/gpio/gpio.l_i386: cannot open shared object file: No such file or directory gpio 17 ... couldn't create Where is the fault? Best Ingirafn On 11/12/2013 12:31 PM, Julian Brooks wrote: Hi Ingirafn, This is the one that Jaime put together. Best of luck with it all, Julian On 12 November 2013 11:20, Ingirafn Steinarsson ingir...@this.is mailto:ingir...@this.is wrote: Hello. I found this thread and I am trying to compile the on the raspberry pi. I think I managed to but I was wondering where the gpio-help.pd files mentioned exist . Best Ingirafn ___ Pd-list@iem.at mailto: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
Re: [PD] Strip file name from path (alternative to [stripfilename])?
On 2013-10-30 11:07, peiman khosravi wrote: Hello, I don't have windows to test this. Is it that the external is not loading at all or there is a problem with the format of the path? The source code for [basedir] is only compiled if _WIN32 is not defined. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 2013-10-22 13:14, Jonathan Wilkes wrote: On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. I think Apple hardware has a MTBF of about 3 years; their business model relies on customers junking the old model at ever increasing rates and buying the new one. The old one after all never quite worked properly because they sold it before it was ready. I have a bunch of old Macs around here that mostly won't start up anymore. Usually the hard drive or the power supply fails. Good luck replacing either. I'm pissed because I've lost a lot of my work that way and with the constant incompatibility from one version of MacOS to the next not to mention the uninteroperability with any other OS. So anyway PPC is obsolete and such a machine trying to run a new version of any software would probably choke on it anyway. And OSX on PPC was really slow, system9 worked better. I think the best thing is to not upgrade at all and try to keep it running the old software while not stressing the hardware in any way. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
On 2013-10-09 22:45, Jonathan Wilkes wrote: Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running. Minefields: ... * I can't figure out how to build the externals in extra. If I do make the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory. The linker won't be looking for m_pd.h. It wants the Pd librrary as -lpd Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] TouchOSC makes Pd crash, on UbuntuStudio, not in Ubuntu
I think it's all fixed now, in svn. Anything not an OSC message is now routed to the rightmost outlet, without prefixing a slash. Let me know if it works or not for you. Thanks for finding the bug! Martin On 2013-09-16 17:22, Matthias Kronlachner wrote: ok its even more simple than that.. a |bang( crashes routeOSC :-) and a bang is sent to the outlet of routeOSC if a message has no argument... On 9/16/13 11:51 PM, Martin Peach wrote: OK, thanks for this. Any idea what the message is that is causing the crash? Is it valid OSC? Martin ___ 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] TouchOSC makes Pd crash, on UbuntuStudio, not in Ubuntu
It sounds like you have two issues: one is that the new external crashes Pd as soon as it is instantiated, the other is that some OSC messages do the same thing when [routeOSC] is involved. For the second thing, just use [udpreceive] | [unpackOSC] | [print] and switch pages to see what raw message is being sent. For the first thing, make a new patch and put a [routeOSC] in it and see what the console prints. But then again you don't seem to be able to start Pd at all from the console. Is that correct? Martin On 2013-09-16 12:08, Mario Mey wrote: Thanks, Martin. I compiled it and test it. Again, in UbuntuStudio 12.04.3, it makes PureData crash. There's no message, it just crashs. Is anything I could do to help to avoid that? How could I debug it? In the other hand, I'm having troubles to launch Pd from console (to see if any message is there)... it can't open my patch. So, I'm writting another mail to list. 2013/9/15 Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca On 2013-09-15 16:12, Mario Mey wrote: I just downloaded complete PureData from svn... but I want to compile only your externals. Is that possible? I think so... how? From trunk/externals type make mrpeach or make mrpeach_install (which doesn't actually install the files, it puts them in externals/build/lib/pd-extended/extra) Martin Thank you. 2013/9/15 Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca On 2013-09-14 19:28, Mario Mey wrote: Martin Peach, I read somewhere that changing pages in TouchOSC makes Pd (or Pd-Ext) to crash. My Pd-Extended doesn't crash, but this error is shown: * routeOSC: ignoring empty list…. That doesn't happen here. There is no such message in the source code. Maybe you have an older version of routeOSC? The OSC specification allows empty messages, and [routeOSC] should output a bang if it routes such a message. Older versions of [routeOSC](before March 2012) didn't work properly, so you probably just need to find a more recent one or build it from svn. (http://sourceforge.net/p/__pure-data/svn/HEAD/tree/trunk/__externals/mrpeach/osc/ http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/osc/) Martin Today, I've installed Ubuntu Studio 12.04.3 (with lowlatency kernel). It seemed that it was a good distro for my use... but switching pages DOES make Pd-Extended to crash. I reported-suggested this in this thread: http://hexler.net/forum/__viewthread/992/ http://hexler.net/forum/viewthread/992/, where I wrote some other info, maybe usefull. The config where it doesn't crash: /Ubuntu 12.04, Kernel 3.2.0-49-generic, Pd-Extended 0.43.4 (download from PPA as the Pure Data page says), jackdmp 1.9.8...// / The other config: /Ubuntu Studio 12.04.3, Kernel 3.2.0-51-lowlatency, same Pd-Extended version, Jack that came with UbuntuStudio (don't know wich version)/ Any other information that could be useful to fix this? Like I wrote in the thread, I suggested TouchOSC that it should send non-empty lists. But, TouchOSC is closed-code... so, there's no easy feedback. _ Pd-list@iem.at mailto:Pd-list@iem.at mailto:Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/__listinfo/pd-list 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
Re: [PD] TouchOSC makes Pd crash, on UbuntuStudio, not in Ubuntu
OK, thanks for this. Any idea what the message is that is causing the crash? Is it valid OSC? Martin On 2013-09-16 16:12, Matthias Kronlachner wrote: Hi! I experience this bug today as well. Attached is a Pd-patch that simulates this crash caused by the message TouchOSC is sending if page is turned (although this can be changed in the TouchOSC editor!). This is the gdb output: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x045f1c59 in routeOSC_list (x=0x5e5990, s=0x0, argc=0, argv=0x0) at routeOSC.c:410 410if (argv[0].a_type == A_SYMBOL) routeOSC_doanything(x, argv[0].a_w.w_symbol, argc-1, argv[1]); I attached an easy fix for routeOSC.c So either rebuild routeOSC with the fix or change the message TouchOSC is sending on page turn. (This is done by deactivating the auto checkbox below Page, Name and OSC) Matthias On 9/16/13 7:46 PM, Martin Peach wrote: It sounds like you have two issues: one is that the new external crashes Pd as soon as it is instantiated, the other is that some OSC messages do the same thing when [routeOSC] is involved. For the second thing, just use [udpreceive] | [unpackOSC] | [print] and switch pages to see what raw message is being sent. For the first thing, make a new patch and put a [routeOSC] in it and see what the console prints. But then again you don't seem to be able to start Pd at all from the console. Is that correct? Martin On 2013-09-16 12:08, Mario Mey wrote: Thanks, Martin. I compiled it and test it. Again, in UbuntuStudio 12.04.3, it makes PureData crash. There's no message, it just crashs. Is anything I could do to help to avoid that? How could I debug it? In the other hand, I'm having troubles to launch Pd from console (to see if any message is there)... it can't open my patch. So, I'm writting another mail to list. 2013/9/15 Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca On 2013-09-15 16:12, Mario Mey wrote: I just downloaded complete PureData from svn... but I want to compile only your externals. Is that possible? I think so... how? From trunk/externals type make mrpeach or make mrpeach_install (which doesn't actually install the files, it puts them in externals/build/lib/pd-extended/extra) Martin Thank you. 2013/9/15 Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca On 2013-09-14 19:28, Mario Mey wrote: Martin Peach, I read somewhere that changing pages in TouchOSC makes Pd (or Pd-Ext) to crash. My Pd-Extended doesn't crash, but this error is shown: * routeOSC: ignoring empty list…. That doesn't happen here. There is no such message in the source code. Maybe you have an older version of routeOSC? The OSC specification allows empty messages, and [routeOSC] should output a bang if it routes such a message. Older versions of [routeOSC](before March 2012) didn't work properly, so you probably just need to find a more recent one or build it from svn. (http://sourceforge.net/p/__pure-data/svn/HEAD/tree/trunk/__externals/mrpeach/osc/ http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/osc/) Martin Today, I've installed Ubuntu Studio 12.04.3 (with lowlatency kernel). It seemed that it was a good distro for my use... but switching pages DOES make Pd-Extended to crash. I reported-suggested this in this thread: http://hexler.net/forum/__viewthread/992/ http://hexler.net/forum/viewthread/992/, where I wrote some other info, maybe usefull. The config where it doesn't crash: /Ubuntu 12.04, Kernel 3.2.0-49-generic, Pd-Extended 0.43.4 (download from PPA as the Pure Data page says), jackdmp 1.9.8...// / The other config: /Ubuntu Studio 12.04.3, Kernel 3.2.0-51-lowlatency, same Pd-Extended version, Jack that came with UbuntuStudio (don't know wich version)/ Any other information that could be useful to fix this? Like I wrote in the thread, I suggested TouchOSC that it should send non-empty lists. But, TouchOSC is closed-code... so, there's no easy feedback. _ Pd-list@iem.at mailto:Pd-list@iem.at mailto:Pd-list
Re: [PD] TouchOSC makes Pd crash, on UbuntuStudio, not in Ubuntu
On 2013-09-14 19:28, Mario Mey wrote: Martin Peach, I read somewhere that changing pages in TouchOSC makes Pd (or Pd-Ext) to crash. My Pd-Extended doesn't crash, but this error is shown: * routeOSC: ignoring empty list…. That doesn't happen here. There is no such message in the source code. Maybe you have an older version of routeOSC? The OSC specification allows empty messages, and [routeOSC] should output a bang if it routes such a message. Older versions of [routeOSC](before March 2012) didn't work properly, so you probably just need to find a more recent one or build it from svn. (http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/osc/) Martin Today, I've installed Ubuntu Studio 12.04.3 (with lowlatency kernel). It seemed that it was a good distro for my use... but switching pages DOES make Pd-Extended to crash. I reported-suggested this in this thread: http://hexler.net/forum/viewthread/992/, where I wrote some other info, maybe usefull. The config where it doesn't crash: /Ubuntu 12.04, Kernel 3.2.0-49-generic, Pd-Extended 0.43.4 (download from PPA as the Pure Data page says), jackdmp 1.9.8...// / The other config: /Ubuntu Studio 12.04.3, Kernel 3.2.0-51-lowlatency, same Pd-Extended version, Jack that came with UbuntuStudio (don't know wich version)/ Any other information that could be useful to fix this? Like I wrote in the thread, I suggested TouchOSC that it should send non-empty lists. But, TouchOSC is closed-code... so, there's no easy feedback. ___ 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] Wish Error : Unable to alloc xxx bytes
Without seeing the patch I can't say but it sounds like something is receiving too much too fast. Martin On 2013-09-07 01:17, jim wrote: Hello , I keep getting an error that is crashing a patch. As shown above it is Unable to alloc xxx bytes where xxx seems to be different each time it crashes. The patch uses mrpeach's udpsend. Not sure if I am doing something wrong with udpsend or it is something else. The patch also takes in data from a com port. This error is happening in Windows , however in Linux the same patch in combination with the other program I am sending data to via udpsend locks up my machine. Any thought where an Unable to alloc ... error comes from in pd. Thanks, Jim ___ 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] MIDIFILE read Tempo
On 2013-09-05 07:04, Maciej Sledziecki wrote: Hello, ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ? It's been a while since I worked on that but I think you can dump the info and use that to set up a metro. I could probably add a message to get it to play automatically. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDIFILE read Tempo
On 2013-09-05 09:29, Martin Peach wrote: On 2013-09-05 07:04, Maciej Sledziecki wrote: Hello, ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ? It's been a while since I worked on that but I think you can dump the info and use that to set up a metro. I could probably add a message to get it to play automatically. If you bang the [midifile] after opening the file, the right outlet will emit ticks_per_quarternote and microsec_per_quarternote messages. So the millisecond rate for the [metro] would be = (microsec_per_quarternote/ticks_per_quarternote)/1000 See attached patch. Martin #N canvas 421 249 558 483 10; #X declare -lib mrpeach; #X obj 320 12 import mrpeach; #X obj 155 164 midifile; #X obj 200 340 /; #X obj 200 366 / 1000; #X obj 155 135 metro 2; #X obj 200 394 s ms_tempo; #X obj 194 108 r ms_tempo; #X obj 155 109 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X floatatom 213 214 7 0 0 0 - - -; #X floatatom 367 214 7 0 0 0 - - -; #X floatatom 204 135 7 0 0 0 - - -; #X msg 64 147 rewind; #X obj 60 54 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 122 29 Read the midi file and bang it once to get the tempo into the metro; #X text 14 29 1; #X text 39 55 2; #X text 133 106 3; #X text 157 74 or just start the metro and it will adjust after the first tick; #X obj 39 0 openpanel; #X msg 39 31 read \$1; #X obj 39 -18 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 200 184 route microsec_per_quarternote ticks_per_quarternote ; #X connect 1 2 21 0; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 6 0 4 1; #X connect 6 0 10 0; #X connect 7 0 4 0; #X connect 11 0 1 0; #X connect 12 0 1 0; #X connect 18 0 19 0; #X connect 19 0 1 0; #X connect 20 0 18 0; #X connect 21 0 8 0; #X connect 21 0 2 0; #X connect 21 1 9 0; #X connect 21 1 2 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC crash
On 2013-08-28 19:21, Martin Peach wrote: So that translates as #bundle, timetag=0, size of first element = 12 / ,f 0 So it's opening a bundle with an element whose path is just / and a float equal to zero. It could be that totalMix opens the bundle and only closes it at the end, which would probably make Pd crash since it expects to get the entire bundle before processing it. Actually that's not true. The bundle is complete in that message. I tried passing those numbers as a message [35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0( through [unpackOSC] here and it doesn't complain. So something else is wrong. Martin Martin On 2013-08-28 18:25, Max wrote: now suddenly it seems to crash when starting totalMix instead of quitting it. I've started pd with -stderr and it spills out: udpreceive: 35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0 Am 29.08.2013 um 00:12 schrieb Martin Peach martin.pe...@sympatico.ca: It sounds like TotalMix is sending something that is not OSC when it shuts down. Can you provide the output of udpreceive when that happens? Maybe put a [print] after [udpreceive]. Martin On 2013-08-28 17:35, Max wrote: when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin0x0af8c404 routeOSC_list + 16 1 pd0x0002a7d1 pd_defaultbang + 65 2 pd0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin0x0af8bf3c routeOSC_doanything + 509 4 pd0x0002b7f8 pd_typedmess + 824 5 pd0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin 0x09ff3ea3 udpreceive_read + 406 ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC crash
On 2013-08-29 12:20, Max wrote: Am 29.08.2013 um 18:17 schrieb Martin Peach martin.pe...@sympatico.ca: On 2013-08-28 19:21, Martin Peach wrote: So that translates as #bundle, timetag=0, size of first element = 12 / ,f 0 So it's opening a bundle with an element whose path is just / and a float equal to zero. It could be that totalMix opens the bundle and only closes it at the end, which would probably make Pd crash since it expects to get the entire bundle before processing it. Actually that's not true. The bundle is complete in that message. I tried passing those numbers as a message [35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0( through [unpackOSC] here and it doesn't complain. So something else is wrong. if i can do something to find out what's going on, then let me know asap. i will have no more access to a os x machine from tomorrow on. Can you run wireshark to get the content of a packet that causes a crash? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC crash
On 2013-08-29 12:20, Max wrote: Am 29.08.2013 um 18:17 schrieb Martin Peach martin.pe...@sympatico.ca: On 2013-08-28 19:21, Martin Peach wrote: So that translates as #bundle, timetag=0, size of first element = 12 / ,f 0 So it's opening a bundle with an element whose path is just / and a float equal to zero. It could be that totalMix opens the bundle and only closes it at the end, which would probably make Pd crash since it expects to get the entire bundle before processing it. Actually that's not true. The bundle is complete in that message. I tried passing those numbers as a message [35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0( through [unpackOSC] here and it doesn't complain. So something else is wrong. if i can do something to find out what's going on, then let me know asap. i will have no more access to a os x machine from tomorrow on. If it's [routeOSC] that crashes then it might have something to do with the path(s) its looking for. Does it still crash if you disconnect the input to [routeOSC]? Or if you use [route] instead? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
You can send ambiguous floats like this:
[sendtyped /to/totalmix f 1{
|
[packOSC]
Martin
On 2013-08-28 14:33, Max wrote:
Hi List, has anyone used OSC o control RME's TotalMix application? The OSC
support in there seems rather flawed, for instance the float messages seem to
require 1.0 format and 1 will be wrong. How can I sent floats in Pd which have
a zero decimal?
m.
___
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] RME TotalMix controlled with OSC
On 2013-08-28 16:44, Claude Heiland-Allen wrote: Looking at the source, there seems to be a way to set explicit type tags. I haven't checked the help patch, maybe it is documented there. On 28/08/13 21:26, Dan Wilcox wrote: I was thinking that [packOSC] might be interpreting a non-decimal float as an int, but I don't think so ... There is no other way it could be happening - because messages are arrays of atoms and there are no int atoms: Yes, that's why. The default behaviour of [packOSC] checks if an incoming float is the same as its integer representation, if it is, send it as an integer. If Pd used the int atom it wouldn't need to do that. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC crash
It sounds like TotalMix is sending something that is not OSC when it shuts down. Can you provide the output of udpreceive when that happens? Maybe put a [print] after [udpreceive]. Martin On 2013-08-28 17:35, Max wrote: when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 1 pd 0x0002a7d1 pd_defaultbang + 65 2 pd 0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 4 pd 0x0002b7f8 pd_typedmess + 824 5 pd 0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd 0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin0x09ff3ea3 udpreceive_read + 406 ___ 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] routeOSC crash
So that translates as #bundle, timetag=0, size of first element = 12 / ,f 0 So it's opening a bundle with an element whose path is just / and a float equal to zero. It could be that totalMix opens the bundle and only closes it at the end, which would probably make Pd crash since it expects to get the entire bundle before processing it. Martin On 2013-08-28 18:25, Max wrote: now suddenly it seems to crash when starting totalMix instead of quitting it. I've started pd with -stderr and it spills out: udpreceive: 35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0 Am 29.08.2013 um 00:12 schrieb Martin Peach martin.pe...@sympatico.ca: It sounds like TotalMix is sending something that is not OSC when it shuts down. Can you provide the output of udpreceive when that happens? Maybe put a [print] after [udpreceive]. Martin On 2013-08-28 17:35, Max wrote: when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 1 pd 0x0002a7d1 pd_defaultbang + 65 2 pd 0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 4 pd 0x0002b7f8 pd_typedmess + 824 5 pd 0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd 0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin0x09ff3ea3 udpreceive_read + 406 ___ 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
Re: [PD] Pd to Raspberry Pi SPI
It might be better to extend [comport] to handle SPI devices. Assuming you have a /dev/spidev* already existing (I just spent a couple of days getting that far on a Beaglebone Black), the rest of it is quite similar to ordinary asynchronous serial communications. Martin On 2013-08-23 16:21, Dan Nigrin wrote: Background: I'm very well versed in Max, but still a newbie in Pd. I'm working on a project to that will use Pd running on a Raspberry Pi, and that will generate control voltages using DACs (ideally something like a MCP4922 or similar, http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en020399 ). I know about Miller's gpio external, found here: http://crca.ucsd.edu/~msp/syllabi/206.13w/index.htm , but it does not do any of the SPI interfacing, which is the way that will need to interface with the DACs. Is there any possibility (Miller or anyone smarter than I am on this stuff) to extend the gpio external to include SPI interfacing? Thanks in advance, Dan -- Dan Nigrin / Defective Records / http://defectiverecords.com CycliC, M185 Klee Sequencers / MC-4 MC-202 Hack / Audio Plugin Player / General MIDI Player / Major Malfunction Jack OS X / http://jackosx.com ___ 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] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
It depends on the colour and the LED technology. The energy of red light is about 1.5eV and blue is 3eV. Add to that internal resistance of the device. An ordinary diode (not a LED) emits infrared around .6eV, which is the voltage drop of a silicon junction. Martin On 2013-08-07 20:02, Ed Kelly wrote: Oh, thanks. That was dumb I didn't remember that! Is it really 2 volts drop for an LED? I should know this stuff... Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ *From:* Mikael Fernström mikael.fernst...@ul.ie *To:* Ed Kelly morph_2...@yahoo.co.uk *Cc:* Charles Z Henry czhe...@gmail.com; Epic Jefferson jeffreyconcepc...@gmail.com; pd-list pd-list@iem.at *Sent:* Thursday, 8 August 2013, 0:26 *Subject:* Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue note that you have to subtract the voltage drop over the LED, hence it's R = (Vsupply - Vled)/ Iled, e.g. (5-2)/0.02 = 150 Ohm /Mikael On 8 Aug 2013, at 00:19, Ed Kelly morph_2...@yahoo.co.uk mailto:morph_2...@yahoo.co.uk wrote: Check Ohm's law. V=IR, so the resistor you choose is the voltage you provide to the LED divided by the current it draws. e.g. if the LED draws 20mA and you power it from 5V, then the resistor you need is 5/0.02 = 250 ohms in series with the LED. This current is drawn from the positive voltage supply through the resistor and then the LED, and then the transistor. This is a fairly good tutorial: http://www.ehobbycorner.com/pages/tut_transistors.html Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ *From:* Charles Z Henry czhe...@gmail.com mailto:czhe...@gmail.com *To:* Epic Jefferson jeffreyconcepc...@gmail.com mailto:jeffreyconcepc...@gmail.com *Cc:* pd-list pd-list@iem.at mailto:pd-list@iem.at *Sent:* Wednesday, 7 August 2013, 20:41 *Subject:* Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com mailto:jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables
Re: [PD] Reverse Kickstarter Update
On 2013-07-31 11:59, Jamie Bullock wrote: On 31 Jul 2013, at 16:46, Jonathan Wilkes jancs...@yahoo.com wrote: Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an apply or connect or anything button — you just change a setting and that's it — done! Hence my question about when you would want to not apply the settings. I can't find any other application on my Mac that has an apply button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible. My question: are all current (and imaginable future) audio APIs able to handle quick changes to the setttings? Say, if a user toggles Use Callbacks three times within 500ms and Pd tries to connect to ALSA each time, does ALSA handle that gracefully? (Or whatever backend-- I can't remember if ALSA has that option available atm.) I think that's a separate issue to whether or not you have an apply button. That is, you could have an apply button, but still be in a situation where the user can change state faster than the backend can respond. In any case, I think adding a UI component the purpose of which is to throttle user input is a bad idea. I don't want to be slowed down ;) I think you should design what you think is the best UI for humans, and then figure out how to make the business logic robust enough to handle problematic cases like the one you describe above as and when they arise. What if someone wants to change two or more settings without having them activated until all is correct? On the Mac network settings you have an apply button so you can change multiple things without getting stupid error messages because it's only half set up... Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi Behringer UCA222 boot problems
Maybe your power supply can't handle the load? 2 Amps regulated 5V is good, 1 Amp might not do it. Martin On 2013-07-27 05:51, John Canning wrote: Hi Dan, I have done some more hunting around and on the Pd FrontPage site it says that my Behringer soundcard has been proven to work with the Raspberry Pi with reduced USB speed and I have found some posts that say they have it running in full duplex. What I get is something like this when I have the sound card plugged in on boot [2.469784] usb 1-1.3: new high-speed USB device number 4 using dwc_otg [2.571518] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608 [2.571545] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [2.571562] usb 1-1.3: Product: USB2.0 Hub [2.573135] hub 1-1.3:1.0: USB hub found [2.573640] hub 1-1.3:1.0: 4 ports detected [2.849881] usb 1-1.3.4: new full-speed USB device number 5 using dwc_otg [2.953034] usb 1-1.3.4: New USB device found, idVendor=08bb, idProduct=2704 [2.953064] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [2.953081] usb 1-1.3.4: Product: USB Audio DAC [2.953096] usb 1-1.3.4: Manufacturer: Burr-Brown from TI [2.958781] input: Burr-Brown from TI USB Audio DACas /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4:1.2/input/input0 [2.960263] hid-generic 0003:08BB:2704.0001: input,hidraw0: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-bcm2708_usb-1.3.4/input2 and it just hangs there. This is with nothing else plugged in to the PI. Without the lowered USB speed I get so many dropouts that it is completely unusable. I'm sorry to keep harping on about the same thing but as with all of these things you find a little nugget that gives you hope (and another and another). The videos that I have seen like this http://hackaday.com/2013/01/28/raspberry-pi-becomes-a-guitar-effects-processor/ are pretty much what I'm looking for. Imperceptible/minimal dropouts and decent FX. Can you or anyone tell me why I can't even boot the Pi with the (previously community tested) soundcard plugged in running at USB 1 speed? Or why if I plug it in after booting I crash the Pi? This post http://lists.puredata.info/pipermail/pd-list/2013-01/100560.html and others in the same thread are what started me on this mission so if any of the contributors to it could tell me how they have got this up and running I would eternally grateful Thanks again, John On Sat, Jul 27, 2013 at 12:26 AM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: For what it's worth, I tried force ing USB 1.1 mode on the pi with my UA-25 and that resulted in a hard lock as well. Disappointing at this point since I've worked with audio on slower embedded machines before ... On Jul 26, 2013, at 7:19 PM, John Canning johnnyboy7...@hotmail.co.uk mailto:johnnyboy7...@hotmail.co.uk wrote: Thanks for getting back to me Dan On Fri, Jul 26, 2013 at 11:50 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: Actually I miss-typed. The issue is with Isochronous usb mode: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28t=29226 Looks like things should be better for USB 2 audio devices, but still issues with USB 1.1 devices (aka mine :P): While Isoc has improved for pretty much everyone using USB2.0 devices (USB1.1 will still suffer from lost packets due to split transaction breakage noted elsewhere) I'm still annoyed at my webcams kinda working - I get 1-2 seconds of uninterrupted video and then a half-garbled frame. On Jul 26, 2013, at 6:35 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: Sure, but that's only for certain types of USB devices. Some are working and others aren't. More professional sound cards require lower-latency/burst mode over USB which the PI firmware currently doesn't allow and/or doesn't set the correct priority for. The issue AFAICT is that essentially the usb host is software defined on the SOC and they haven't optimized it for usb audio, or something like that. For instance, I can get stereo out in Pd working fine with my Edirol UA-25 . If I enable an audio input, I get instant dropouts. Yeah, I guess it works, but not well enough for me. On Jul 26, 2013, at 6:27 PM, John Canning johnnyboy7...@hotmail.co.uk mailto:johnnyboy7...@hotmail.co.uk wrote: Hi Dan, Thanks for getting back to me. I'm still very new to the Pi but have found this post that seems to say that it can work. I'm confused. What do you reckon? On Fri, Jul 26, 2013 at 11:02 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote:
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
On 2013-07-02 16:13, Roman Haefeli wrote: On Die, 2013-07-02 at 17:07 +0200, Matthias Geier wrote: Hi Iain. To be honest, I didn't think about the problem that a message could need more than one packet. It's good to know that iemnet/tcpclient can handle that. It's not that [iemnet/tcpclient] can handle it and [net/iemnet] can't. In fact, with both you have to cook your own mechanism to delimit packets for a packet oriented protocol. With [net/iemnet], however, you have to serialize the data first in order to be able to do that. I see two problems with [net/tcpclient]'s implementation: * you have to serialize the data anyway, so why doesn't the object already do it? I think I implemented it that way because it seems to be more efficient within Pd to deal with a single list rather than a bunch of floats. But I don't know for sure if that is true. * It gives you the false impression of dealing with packets when you in fact are dealing with a stream. It's dangerous because it often looks as if it would be working, but there is no guarantee it will always do. You may receive a packet split into many chunks, or you get a big chunk containing several packets. All those cases are valid from to POV of TCP, but will break your protocol unless you deploy proper delimiting. Well the TCP protocol _is_ splitting a stream into packets. It's not the same as a serial link where you can send bytes one at a time whenever you like. If you try that you will find that the bytes are gathered into packets for you. It might be useful to consider this when thinking about the best way to send the data (e.g. one byte per packet is not efficient, and you might get the false impression that TCP doesn't work very well). And as I always say, UDP is probably a better choice for what you are trying to do, if it involves real-time control, with UDP you _do_ have control over the packet size. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
It could be that you are overloading Pd with too many messages. If you are wildly moving the slider and [tcpclient] is sending one TCP packet per value you can add messages to the queue faster than they will be sent out and Pd will eventually run out of resources. Maybe put a [speedlim] after your slider, or pack several values into one message? Martin On 2013-07-01 11:53, Iain Mott wrote: I'll try the backtrace and other things you suggest and report back on mrpeach/tcpclient in another email. it could well be, that it only does not crash with [iemnet/tcpclient] because you haven't parsed the output yet... Don't think so - to crash Pd, I wasn't doing any parsing of incoming messages - just sending messages out. Did a backtrace using mrpeach/tcpclient - on a freeze as it didn't actually crash. Got this response: #0 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x in ?? () Will do some more tests later. Thanks, ___ 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] pd-extended crashes sending data to SSR with tcpclient
Forty times a second is relatively slow. Must be something else. I would use wireshark to see what packets are actually going over the wire, especially to see what the last one is. These speeds are probably too fast for [print]ing to the console; that can cause problems. Are you sending to the same machine? If not is WiFi involved? Can you use UDP instead of TCP (for lower overhead and no out-of-order packets)? Martin On 2013-07-01 13:58, Iain Mott wrote: Hi Martin, The actual patch I'm using is translating MIDI pitch bend data recorded in Ardour3 (location data encoded as pitchbend for practical purposes), translating it into XML and sending it through to the SSR. It's already limiting the rate to 10 messages every second for each moving source and so far I'm only using 4 sources. This rate, done for testing, is already less than ideal. Each location message sent SSR for a given source looks something like the following: requestsource id=1position x=1.234 y=-0.234//source/request Does this seem excessive? Cheers, Iain Em Mon, 2013-07-01 às 13:20 -0400, Martin Peach escreveu: It could be that you are overloading Pd with too many messages. If you are wildly moving the slider and [tcpclient] is sending one TCP packet per value you can add messages to the queue faster than they will be sent out and Pd will eventually run out of resources. Maybe put a [speedlim] after your slider, or pack several values into one message? Martin On 2013-07-01 11:53, Iain Mott wrote: I'll try the backtrace and other things you suggest and report back on mrpeach/tcpclient in another email. it could well be, that it only does not crash with [iemnet/tcpclient] because you haven't parsed the output yet... Don't think so - to crash Pd, I wasn't doing any parsing of incoming messages - just sending messages out. Did a backtrace using mrpeach/tcpclient - on a freeze as it didn't actually crash. Got this response: #0 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x in ?? () Will do some more tests later. Thanks, ___ 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] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
On 2013-06-26 03:51, Charles Goyard wrote: Hi, this is largely off-topic, but there you go :) Epic Jefferson wrote: I've had progress building an Arduino-powered solenoid system for a controlling a piano's hammer mechanism (removing the keys) via pd. So far I've found the solenoid I want to use. With solenoids you will not get velocity (or at least, not reliably). You can vary the on-time of the solenoid to get velocity. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] High CPU usage when tracks are muted (Raspberry Pi)
On 2013-05-05 13:52, Halfdan Mouritzen wrote: Yes, what I don't understand though is _why_ we see such an increase in CPU load, when the channels are muted. Could it be that denormals are produced when the line gets close to 0? Depending on how the floating point is set up that could cause a lot of context switching. What happens if you fade to 0.001 instead of 0? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UA-25 on RPI
On 2013-05-04 12:50, Dan Wilcox wrote: No thanks. The UA-25 is bus powered, has two XLR+jack inputs, phantom power, rca/jack outputs, direct monitor, individual channel gain control, master gain control, and in a road tuff metal case. I have two of them, so it makes sense to dump the PI if I can't get it to work with proven linux friendly hardware especially when the pi costs less. Too bad. Back to iPad now ... :D Maybe a beaglebone black: http://beagleboard.org/Products/BeagleBone%20Black I have a Behringer UCA202 running on a beaglebone with no problems. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-05-03 12:34, Julian Brooks wrote: Ok - thanks for that, makes more sense now. When I run the C code this happens: ./jb_d6t_reader_ic3 0 ...export file accessed, new pin now accessible ...direction set to output ./jb_d6t_reader_ic3: initialized:0 Write failed (5) Input/output error ...unexport file accessed, pin now inaccessible I've done my best to go through the code and make changes where appropriate. Replaced D6T8L with DRT44L2 and changed packet size. Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to 0 for rev1 board. Weirdly I can't access the i2c bus anymore? cat /dev/i2c* cat: /dev/i2c-0: Input/output error cat: /dev/i2c-1: Input/output error Yes I get that too. (unless the sensor returns one byte it's probably normal) But i2cdetect -y 1 still shows a sensor at 0x0A. I run the code as sudo ./d6t_reader 0, otherwise I don't have permission to set the GPIO pin. I don't get any write errors though. Are you writing to the correct i2c? There are two places in the code that could throw the write error. Maybe change the message so you can tell which one it is. Anyway the setup should work with the old code (only one sensor), the 4051 circuit should have no effect on the communication betwen the Pi and one of the sensors, the select pin select which sensor receives the clock. So if the older code isn't working the circuit is wrong, otherwise the code is buggy. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup. Martin On 2013-04-25 20:04, Julian Brooks wrote: Just spotted this: https://github.com/kadamski/i2c-gpio-param Could be useful On 25 April 2013 15:54, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-04-25 10:37, Julian Brooks wrote: 'Nother 2 dumb questions: What's the difference between the ones that have spider/centipede type legs and the straight ones (which would be best to get). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin #N canvas 2 0 1015 665 10; #X obj 34 21 unpack 1 2 3 4 5 6 7 8 9; #X obj 34 -51 netreceive 3 1; #X floatatom 34 147 5 0 0 0 - - -; #X floatatom 74 147 5 0 0 0 - - -; #X floatatom 114 147 5 0 0 0 - - -; #X floatatom 154 147 5 0 0 0 - - -; #X floatatom 194 147 5 0 0 0 - - -; #X floatatom 234 147 5 0 0 0 - - -; #X floatatom 274 147 5 0 0 0 - - -; #X floatatom 314 147 5 0 0 0 - - -; #X floatatom 354 146 5 0 0 0 - - -; #X obj 57 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -260097 -1 -1 6756 1; #X obj 77 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6782 1; #X obj 97 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6731 1; #X obj 117 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6350 1; #X obj 137 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6502 1; #X obj 157 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6604 1; #X obj 177 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 6756 1; #X obj 197 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 7188 1; #X obj 217 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034 -1 -1 7137 1; #X obj 34 -11 route d6t8l d6t44l; #X obj 462 6 unpack 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17; #X floatatom 416 41 5 0 0 0 - - -; #X floatatom 479 201 5 0 0 0 - - -; #X floatatom 602 201 5 0 0 0 - - -; #X floatatom 719 201 5 0 0 0 - - -; #X floatatom 843 201 5 0 0 0 - - -; #X floatatom 480 269 5 0 0 0 - - -; #X floatatom 601 269 5 0 0 0 - - -; #X floatatom 720 269 5 0 0 0 - - -; #X floatatom 842 269 5 0 0 0 - - -; #X floatatom 482 336 5 0 0 0 - - -; #X floatatom 603 336 5 0 0 0 - - -; #X floatatom 723 336 5 0 0 0 - - -; #X floatatom 846 336 5 0 0 0 - - -; #X floatatom 483 407 5 0 0 0 - - -; #X floatatom 601 407 5 0 0 0 - - -; #X floatatom 723 407 5 0 0 0 - - -; #X floatatom 847 407 5 0 0 0 - - -; #X obj 274 198 cnv 15 24 24 empty p01_rcv empty 20 12 0 14 -211168 -262144 0; #X obj 304 198 cnv 15 24 24 empty p02_rcv empty 20 12 0 14 -174112 -262144 0; #X obj 334 198 cnv 15 24 24 empty p03_rcv empty 20 12 0 14 -170016 -262144 0; #X obj 364 198 cnv 15 24 24 empty p04_rcv empty 20 12 0 14 -182368 -262144 0; #X obj 274 228 cnv 15 24 24 empty p05_rcv empty 20 12 0 14 -137025 -262144 0; #X obj 304 228 cnv 15 24 24 empty p06_rcv empty 20 12 0 14 -174112 -262144 0; #X obj 334 228 cnv 15 24 24 empty p07_rcv empty 20 12 0 14 -194720 -262144 0; #X obj 364 228 cnv 15 24 24 empty p08_rcv empty 20 12 0 14 -202912 -262144 0; #X obj 274 258 cnv 15 24 24 empty p09_rcv empty 20 12 0 14 -132865 -262144 0; #X obj 304 258 cnv 15 24 24 empty p10_rcv empty 20 12 0 14 -198816 -262144 0; #X obj 334 258 cnv 15 24 24 empty p11_rcv empty 20 12 0 14 -256480 -262144 0; #X obj 364 258 cnv 15 24 24 empty p12_rcv empty 20 12 0 14 -260960 -262144 0; #X obj 274 288 cnv 15 24 24 empty p13_rcv empty 20 12 0 14 -149377 -262144 0; #X obj 304 288 cnv 15 24 24 empty p14_rcv empty 20 12 0 14 -231776 -262144 0; #X obj 334 288 cnv 15 24 24 empty p15_rcv empty 20 12 0 14 -260576 -262144 0; #X obj 364 288 cnv 15 24 24 empty p16_rcv empty 20 12 0 14 -260640 -262144 0; #X msg 406 231 \; p01_rcv color \$1 0; #X msg 526 231 \; p02_rcv color \$1 0
Re: [PD] Sensors GPIO Raspberry Pi Pd
Ordinary 5% resistors will work fine. Probably anything from 1k to 100k would work. Most likely you have a loose connection somewhere. Did you try running the bus at a lower speed? If your wiring is long ( 10cm) it may be better to run it slower. Martin On 2013-04-29 17:44, Julian Brooks wrote: Hi Martin / all, Possibly overly-nerdy question here: I'm buying the various bits and pieces we require for the multiplexer and I'm noticing quite a difference in pricing options for the pull-up resistors. There's this one: http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938 which is 86p each. Or there's something like this: http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/9339060 which is 2p each. The former's spec sheet talks about its very low noise ratio and thinking on from reading the sensors spec sheet it's also pushed there to use low-noise components. Do you think it actually makes any difference? I have to buy a minimum 50 of the cheap ones so buying a couple of the dearer ones doesn't actually make much of a difference. It got me thinking as you mentioned that your getting virtually no PEC errors from the sensors whereas as we are getting them very regularly. I had been thinking it was the soldering of those pernickety sensors but could it also be the cheap 4k resistors currently on our board? Cheers, Julian On 29 April 2013 16:38, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: Here's a patch to display data from two D6T sensors on the same I2C bus. The clock line is switched using a 4051 analog multiplexer. The control line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1 of the 4051 (I2C clock connects to X). Because the code accesses the GPIO file system it needs to be run as root. I have two different sensors so the code reads two different packet lengths. Just a proof of concept, there could be up to 8 identical sensors on the same bus with this setup. Martin On 2013-04-25 20:04, Julian Brooks wrote: Just spotted this: https://github.com/kadamski/__i2c-gpio-param https://github.com/kadamski/i2c-gpio-param Could be useful On 25 April 2013 15:54, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca mailto:martin.peach@__sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-04-25 10:37, Julian Brooks wrote: 'Nother 2 dumb questions: What's the difference between the ones that have spider/centipede type legs and the straight ones (which would be best to get). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-29 17:59, Julian Brooks wrote: BTW This is the multiplexer: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109 and the housing: http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846 Think these are right? Yes. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Dspstate~ in puredata
[bang] | [samplerate~] | [44100\ Martin On 2013-04-28 14:08, Olivier Baudry wrote: Dear all My idea is to get sampling rate in pd ___ 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] Sensors GPIO Raspberry Pi Pd
On 2013-04-25 07:10, Julian Brooks wrote: I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup. I do think a more general [i2c] object would be super-useful. Particularly if it could directly open up and access the i2c line. Not sure how he does it but wiringPi has some kind of test routine that figures out what rev board it's on, which is pretty nifty too. If there's a method to incorporate the i2cdetect functions as well then it would be a one-stop-shop - so to speak. Maybe an additional object to [gpio], plus the 2 omron's as externals / or combined into one and that's definitely the start of a new bad-ass lib:) Yesterday I connected a sensor clock line through a MC14051 analog multiplexer running at 3.3V, with the sensor side clock pin pulled up to 3.3V via a 10k resistor and it works fine. The next step is to switch the clock line using a GPIO pin so I can read 2 sensors off the same i2c bus. This setup should work with up to 8 sensors with the same address, using 3 GPIO pins to select a sensor, but the clock line must only be switched between 12c reads. OAN - Really impressed with the C program: the drain on system resources is very minimal. I'm still getting PEC errors on a regular basis though I still think we may have a dodgy connection somewhere down the line - sometimes when i2cdetect the sensor isn't registering and need to give it a little wiggle (not ideal). Also presuming that as the clock is running at 10 cycles that the readings being passed to Pd are set here: char netbuf[256]; in the C code? (could be talking out of my rear-end here I know) And I'm also presuming they can be edited in those multiples (128, 512 etc)? Yes, netbuf is where the string sent to Pd is constructed. It only needs to be as large as the message, I made it too long to be sure it wouldn't cause trouble. The length doesn't need to be a multiple of anything. I haven't started experimenting yet but the plan is to run the installation headless. Is there anything I'll need to change in the code to allow the C program to run from boot: Like at the moment the readings are being spat out in the xterm (stdout) via 'printf' I think, which is also replicated via the [netreceive] patch, so I'm guessing I can start to trim stuff down. You can comment out any lines with 'printf' in them by prefixing a double slash //. I have been running it headless via ssh as: nohup ./d6treader 0 /dev/null This sends all the text output to nowhere and also keeps the program running after I close the connection. (I had it running for a day without redirecting output and it nearly filled up the sd card.) Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
Well, [udpsend~] is meant to work with [udpreceive~], so you really have to run Pd on both ends of the connection. Of course you are free to modify the code to make it work with your setup -- that would mean integrating [udpsend~] into the server and [udpreceive~] into the clients' browsers, which I have no idea how to do. Martin On 2013-04-25 10:14, o...@onyx-ashanti.com wrote: Greetings! I hope all is well with you. I wanted to ask if i might gain some of your insight on a project i am undertaking. I am currently attempting to stream my audio into html5 capable web browsers of smartphones. i have created a local network and installed nginx as my webserver. i and a friend got everything working with the oggcast~ and mp3cast~ objects and the icecast 2 server, but the latency was horrific-5-15seconds. I would like to investigate the idea of taking advantage of the plugin-less nature of these modern fast browsers and pipe the audio directly into it as directly as possible the same way voip works but lower bandwidth and only one way. I see that udpsend~ can do alot of what i think i want, but i am confused as to how i might connect it with the audio socket in the client browser (if socket is even the right term). Any insight would be greatly appreciated. and if i get it working, as before, i will document the findings in a step by step once it works. thank you. cheers! Onyx -- www.onyx-ashanti.com http://www.onyx-ashanti.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-25 10:37, Julian Brooks wrote: 'Nother 2 dumb questions: What's the difference between the ones that have spider/centipede type legs and the straight ones (which would be best to get). The PDIP package is what you want, not the SOIC. The only difference is size. DIP packages are human-friendly, surface mount is for robots. And also are you attaching the MC14051 to any type of board/adaptor or just soldering straight on to the pins? I have it in a breadboard right now, to make it more permanent I would solder a socket to a prototyping board then (after verifying the connections) plug the chip into the socket. Soldering to the pins makes it difficult to replace the IC, and risks damaging it with the heat if you're not good at soldering quickly and to the point. A CD4051 would also work, it's basically the same circuit. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
On 2013-04-25 10:36, o...@onyx-ashanti.com wrote: Thanks for getting back to me do quickly. Is there a network audio object (s) that can output standard formatted audio? I don't know. netjack? The thing with browsers is they run TCP, which is not good for low-latency audio. Maybe you want a separate UDP audio link, but I don't know how to integrate that with a browser. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-23 04:42, Julian Brooks wrote: Hey Martin / all, Omron tech support finally got back to me re the address issue, this is what they had to say: D6T sensor can not change the address. When you connect multiple sensors we recommend that you use the IC switching. Please refer to the below document. http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf I've been through the spec sheet several times and don't see anything (admittedly not sure exactly what I'm looking for though) that relates to IC switching. Seems Digikey stopped selling the part, Mouser has it now (http://ca.mouser.com/ProductDetail/Omron/D6T-44L-06/?qs=%2fha2pyFaduiRuNG9v%2frw9TOAJzjSw0m3hi0MOmJaH6Q%3d), and there's a document there that has something about using multiple sensors on one bus: http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.pdf We've still got 2 of these doing nothing currently if they could be brought into action: http://adafruit.com/products/757 That will only convert levels, it's not a multiplexer. I found that the sensor works fine with the pullups to 3.3V on the RPi. Seems to me the easiest way to multiplex them would be to put a CD4051 on the clock line and use up to 3 GPIO pins to select which of up to 8 sensors receives the clock. The only tricky bit would be making sure the clock is at the right level when the switching tales place, you might need ~10k pullups to 3.3V on the sensor clock pins. Or people on the RPi forum seem to have got the 2nd i2c pins going but that seems to be for rev.2 boards only (I think - have posted a question on the thread to ask). Also asked tech support about the PEC errors but no response to that one. I've noticed that the PEC doesn't trigger errors all the time so am wondering if it's possible to filter the errors out of the data somehow in the C file? Yes that's what happens already. I was getting errors at first because the crc calculation was being done over both the write and read packets. I found that calculating only the read packet gives the correct value almost always. If the PEC is wrong, the code simply asks for another packet. At the moment I'm getting almost no errors. Still delighted though - the sensors great! Yes, it even works as an icecube detector! Martin Cheers, Julian On 22 April 2013 00:20, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Wonder if it's a difference between rev boards on the Pi? I've also built a custom image based on Hexxeh's minimal install which is working great for audio stuff. My Pd patch that wouldn't run without overclocking on a standard Raspian is now working fine on the rev1 256mg board. So I've been adding stuff as and when it comes up to try and keep t is minimal as poss. I'm also not sure what installed libi2c-dev? Guess I'll have to wait and see what squeals. Of possible interest is this message when removing the lib with apt-get: The following packages will be REMOVED: libi2c-dev 0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded. After this operation, 19.5 kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 33610 files and directories currently installed.) Removing libi2c-dev ... Removing 'diversion of /usr/include/linux/i2c-dev.h to /usr/include/linux/i2c-dev.h.kernel by libi2c-dev' So guess the diversion was messing with the compile for the C code. Anyway - code runs and I can compile C files too so all ok so far. Thanks again for everything Martin, Julian On 21 April 2013 06:45, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-04-20 21:09, Julian Brooks wrote: Oh and btw Still don't know why I can't compile the .c files on the pi with libi2c-dev installed but I can't. Presuming the compiling is working for you Martin? Yes it works for me. I don't have the same /usr/include/linux/i2c-dev.h as you so no redefinition errors, not sure which package(s) install that file. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Yes that would work too, if you can handle the soldering ;( I suppose you could modify the c code to run two sensors and send the data to two different port numbers, or use two different selectors for the message. Another way would be to have the Pd patch request a reading from a specific sensor. I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup. Martin On 2013-04-23 05:06, Julian Brooks wrote: Bit more digging re ic switch: My understanding is that if we got one of these: http://uk.farnell.com/roth-elektronik/re933-03/adaptor-smd-tssop-16-0-65mm/dp/1426182 and one of these: http://uk.farnell.com/nxp/pca9546apw/ic-switch-4ch-i2c-16tssop/dp/2212120 we should in theory be able to run both sensors off the same pins? BUT - would the current code you wrote function better/easier if the sensors were run from 2 separate sets of pins - ie how to parse the info from one patch sounds tricky and presume much simpler with 2 [netreceive] objects attached to 2 C files? J On 23 April 2013 09:42, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hey Martin / all, Omron tech support finally got back to me re the address issue, this is what they had to say: D6T sensor can not change the address. When you connect multiple sensors we recommend that you use the IC switching. Please refer to the below document. http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf I've been through the spec sheet several times and don't see anything (admittedly not sure exactly what I'm looking for though) that relates to IC switching. We've still got 2 of these doing nothing currently if they could be brought into action: http://adafruit.com/products/757 Or people on the RPi forum seem to have got the 2nd i2c pins going but that seems to be for rev.2 boards only (I think - have posted a question on the thread to ask). Also asked tech support about the PEC errors but no response to that one. I've noticed that the PEC doesn't trigger errors all the time so am wondering if it's possible to filter the errors out of the data somehow in the C file? Still delighted though - the sensors great! Cheers, Julian On 22 April 2013 00:20, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Wonder if it's a difference between rev boards on the Pi? I've also built a custom image based on Hexxeh's minimal install which is working great for audio stuff. My Pd patch that wouldn't run without overclocking on a standard Raspian is now working fine on the rev1 256mg board. So I've been adding stuff as and when it comes up to try and keep t is minimal as poss. I'm also not sure what installed libi2c-dev? Guess I'll have to wait and see what squeals. Of possible interest is this message when removing the lib with apt-get: The following packages will be REMOVED: libi2c-dev 0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded. After this operation, 19.5 kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 33610 files and directories currently installed.) Removing libi2c-dev ... Removing 'diversion of /usr/include/linux/i2c-dev.h to /usr/include/linux/i2c-dev.h.kernel by libi2c-dev' So guess the diversion was messing with the compile for the C code. Anyway - code runs and I can compile C files too so all ok so far. Thanks again for everything Martin, Julian On 21 April 2013 06:45, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-04-20 21:09, Julian Brooks wrote: Oh and btw Still don't know why I can't compile the .c files on the pi with libi2c-dev installed but I can't. Presuming the compiling is working for you Martin? Yes it works for me. I don't have the same /usr/include/linux/i2c-dev.h as you so no redefinition errors, not sure which package(s) install that file. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-23 09:32, Julian Brooks wrote: ... Maybe there's something I'm missing here then: The average temp that comes out of [unpack 1] is way higher than the rest of the readings. At the moment [unpack 1] says '212' yet a quick averaging of the other 16 readings is around '180'? That's right. The first reading is of an internal reference, it's usually a few degrees warmer than the environment. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Well that looks a total mess... I did sudo apt-get install i2c-dev before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning. Martin On 2013-04-19 17:37, Julian Brooks wrote: As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@ %s ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@0x%02X ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d) BTW - I've removed libi2c-dev again and will leave it that way for now. Going to stop now but will be back tomorrow. Cheers, Julian On 19 April 2013 22:07, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh. I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff). Julian On 19 April 2013 14:36, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708
Re: [PD] Sensors GPIO Raspberry Pi Pd
Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining if (argc 0) should say if (argc 1). Martin On 2013-04-20 13:30, Martin Peach wrote: Well that looks a total mess... I did sudo apt-get install i2c-dev before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning. Martin On 2013-04-19 17:37, Julian Brooks wrote: As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@ %s ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@0x%02X ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d) BTW - I've removed libi2c-dev again and will leave it that way for now. Going to stop now but will be back tomorrow. Cheers, Julian On 19 April 2013 22:07, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh. I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff). Julian On 19 April 2013 14:36, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1
Re: [PD] Sensors GPIO Raspberry Pi Pd
So I tested the 4X4 sensor and it actually works! Here is the code for a reader that sends to [netreceive 3], and a receiver patch. You need to set the IP to that of the machine running Pd, and maybe other settings before compiling, as with the previous version. Martin On 2013-04-20 17:17, Martin Peach wrote: Oh sorry, it segfaults if you don't pass an argument at startup. (1 if it's already initialized, 0 if not) The line begining if (argc 0) should say if (argc 1). Martin On 2013-04-20 13:30, Martin Peach wrote: Well that looks a total mess... I did sudo apt-get install i2c-dev before all this, as well as all the things in http://www.instructables.com/id/Raspberry-Pi-I2C-Python/#step1 except I didn't use any python. The segfaults might be because you are asking for more than 32 bytes in a read, or something wrong in the code, the listing below looks like it goes wrong right at the beginning. Martin On 2013-04-19 17:37, Julian Brooks wrote: As I'm new to all this C stuff I just had a look inside the 'hello' file and there's a few bits in there which may be of interest: ^@D6T_checkPEC says 0x%02X (which I think is ok from looking at the code?) then it all goes wrong ^@^@^@Unable to create socket (%d) ^@^@^@ %s ^@^@^@127.0.0.1 http://127.0.0.1^@^@^@Unable to make address from %s ^@%s: initialized:%d ^@/dev/i2c-0^@^@Failed to open the bus. (%d) ^@^@^@Failed to acquire bus access and/or talk to slave. (%d) ^@^@^@^@Write failed (%d) ^@^@Read failed (%d) ^@^@^@%d ^@0x%02X ^@^@^@d6t8l^@^@^@ %d^@ ^@^@^@sendto error (%d) BTW - I've removed libi2c-dev again and will leave it that way for now. Going to stop now but will be back tomorrow. Cheers, Julian On 19 April 2013 22:07, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Edited your original file and all I changed was the ip address to 127.0.0.1 and still seg fault (double checked /etc/hosts too). Also tried reinstalling libi2c-dev and then running 'hello' - same. On 19 April 2013 21:54, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: hmmm - both files: ./hello-2 Segmentation fault Try again... On 19 April 2013 21:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Ok -found I had to remove 'libi2c-dev'. Then builds. More soon... On 19 April 2013 21:28, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hey Martin, When I try to compile hello.c I get: gcc -o hello hello.c In file included from hello.c:8:0: /usr/include/linux/i2c-dev.h:38:8: error: redefinition of 'struct i2c_msg' /usr/include/linux/i2c.h:67:8: note: originally defined here /usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data' /usr/include/linux/i2c.h:125:7: note: originally defined here Dunno if this is at all relevant but maybe this is a good time to say I have a rev1 RPi so I'm on i2c 0 not 1. The Pi install is very up to date though, including recent runs of hexxeh's 'rpi-update' tool so all the system's fresh. I did attempt to change the number of bytes to be read which perhaps would explain why the .h file's are complaining but I don't understand it for your version which is 'as-is'? In fact why don't I attach the notes I've made of the changes to the c file you sent. Was vaguely hoping I might be able to say 'ta da' but have fallen at the 1st fence:( bugger. Julian On 19 April 2013 19:51, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hi Martin, Meant to add re setting baud rate: I've been making use of the gpio utility that comes with wiringPi https://projects.drogon.net/raspberry-pi/wiringpi/the-gpio-utility/ Very handy for getting a quick visualisation of the current state of all the pins and also easy-access to setting the baud rate too (amongst other stuff). Julian On 19 April 2013 14:36, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-20 21:09, Julian Brooks wrote: Oh and btw Still don't know why I can't compile the .c files on the pi with libi2c-dev installed but I can't. Presuming the compiling is working for you Martin? Yes it works for me. I don't have the same /usr/include/linux/i2c-dev.h as you so no redefinition errors, not sure which package(s) install that file. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Hi Julian, Yes I've been messing with coding it in c on the pi and sending the data to a [netreceive] in a Pd patch on another machine. I'm attaching the source code for the pi part and the Pd patch. The code can be compiled on the pi with gcc -o hello hello.c You need to set the IP address of the receiving machine in the code (I have 192.168.2.15, it could be 127.0.0.1 for the same machine). I tried changing the baud rate with sudo modprobe -r i2c_bcm2708 sudo modprobe i2c)bcn2708 baudrate=9 but it works fine at the default 10. It seems that you only need to write the command once, after that simply reading gets you another packet. Using a combined write/read operation only works half the time, as I also found on the Arduino. All you need to do is write the 0x4C command once, wait a millisecond or so and then read it. Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, so the code reads 19 bytes (need to change the expected read size in the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver maximum, so you may not get the last part of a packet. I'll try it later with a 4X4 sensor to see what happens. Martin On 2013-04-19 07:01, Julian Brooks wrote: Hi Martin, Did you manage to make any progress with the sensor on the Pi? I also wanted to ask whether the output we're receiving from i2cdump makes any sense to you as it doesn't to us currently? Tried searching around for possible info on the 'XX' 'ff' but drawing a blank here. Cheers, Julian On 13 April 2013 01:11, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Hey all, Some success finally: Hurrah!! The scl breakout pin on the pi proto plate wasn't working properly. When unscrewed halfway it works, when fully screwed in it doesn't. So - now got this: i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- 0a -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- and i2cdump -y 0 0xa No size specified (using byte-data access) Gives a whole host of stuff I don't yet understand but I don't care currently as something is actually happening. Will figure out a way of saving the console info (any hints anyone?) as it gets badly mangled when cutting and pasting but basically something like this: i2cdump -y 0 0xa No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX.XX....X 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XXX.X.X.X.XX.X 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff.XX.XX..XXX. 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XXX.X....X 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ffXXX.X.XXXdXX?XX. 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XXX.XXX.XX.XXX 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX.XXX..XX 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XXXXX. 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XXX.XX..XXX.XX 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XXXX.XX.X.X..XX..X a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XXX.XX.X.X b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XXXX.XXX.XX.XX c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX.XX..XX..XXX d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ffX.X.X.X. e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XXXXX.X..X f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX.X..XX.X Progress at least. Cheers, Julian On 12 April 2013 11:27, Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Message resent for thread archives with smaller picture size. Julian -- Forwarded message -- From: *Julian Brooks* jbee...@gmail.com mailto:jbee...@gmail.com Date: 11 April 2013 19:24 Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd To: Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca Cc: PD List pd-list@iem.at mailto:pd-list@iem.at Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-11 14:24, Julian Brooks wrote: Hey Martin / list, Finally got all the stuff and ... It’s not working! We spent the day soldering cables and connecting stuff up as per the Omron ‘App Note 01’ spec sheet. Started off super-conservative using the I2C level converter (case 3 page 4) http://www.adafruit.com/products/757#Blog/Flickr We tried resistors on both sides (being super paranoid!) and then we took the low (Pi) side ones off. We then moved on to case 2 page 3 of this same document… At each stage we checked with “I2Cdetect –Y 1” and nothing was visible. The grid shows no attached devices every time we run it. We re-booted at every stage following the various online tutorials/methods of setting up I2C GPIO on the Pi (checked double checked). As you can see we’re using a pi protoplate: https://www.adafruit.com/products/801 In the photo I’ve attached the cables are coded as follows: Orange GND Yellow5v BlueSCL Green SDA The white is also 5v for the pull up resistors. The resistor values are 4.7k btw. We have tested the cable that terminates at the sensor and all that is OK. I put a multimeter on the GND and SDA solder points on the sensor itself and got 3.7v… I put a multimeter on the GND and SCL solder points on the sensor itself and got 0.0v… If you have pullup resistors you should get the same 3.7V on SCL (with it switched on and not running any code), so probably your pin isn't connected somewhere. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-07 04:30, Julian Brooks wrote: Hey Martin / list, This is all marvellous news. Going a bit slower at our end, not helped by Easter holidays, trips to the seaside (bit chilly) and the plethora of children that require our undivided attention. ebay parts arrived today and don't fit which is annoying to say the least. Spent several hours tracking down the correct housings and pins and then finding somewhere in the U.K. that would sell me less than a hundred housings or a thousand pins. Ended up with 5 and a 100 respectively. Also got a voltage transformer that works with i2c as the rpi is 3.5v and sensors 5v. Am planning on blogging all the info when done but if anyone wants any specifics before then please say. I'm slowly making some headway with getting my head around the gpio pins and setting those up to use with Miller's [gpio]. I can now access the i2c pins via [gpio] and send them 1 or 0 setting the pins hi and lo which is a start. Also found where to set the baud rate from within the RPi which will be useful. Although the sensor mentions 1000k as baud rate I'm thinking that 9600 would be better for overhead reasons. Perhaps we should get it working as is before starting to change too many settings? I2c is a synchronous serial protocol. The clock is transmitted on a separate wire. Usually it runs a lot faster than asynchronous serial. I set the frequency in the Arduino to 800kHz but the sensor was working at 1MHz as well. You control the sample rate by requesting sensor packets at the rate you want. (Or you could bit-bang the gpio pins to get the data manually, but that's very slow) There is a package named i2c-tools that ought to be available for rpi. It has commands like i2cdetect and i2cdump that should detect and read the sensor. Still absolutely no idea how to setup sending and receiving 16b messages plus how to add in the delay but we /will/ get there in the end. I have my pi now so I can get into that as soon as I have time. You write the value 0x4C (76) to address 7 and then request 32 (35) bytes, which are 16 little-endian integers. Any ideas how we would go about formulating messages for this from within Pd? Should we be looking at [comport] at all? No. Somehow you need to access the i2c device, probably the same way you access gpio pins, by writing to pseudofiles somewhere in the system. I've found this to be the most informative info for the d6t so far: http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf With my limited understanding it seems to be saying it's big-endian (msb first, p.4) ? We have 2 sensors so we need to figure out how to set the 7bit addresses. Also that the data bit width is 8 - so I'm confused as to what the 35 bytes are and where they come from? It's a list of bigendian values followed by an error correction code. The first pixel is a reference, usually reads about 24 degrees, the next 16 are the image. The error code is a crc-8. I haven't been able to get the right number for the crc yet, probably because it's calculated on bits not bytes and the 12c protocol inserts bits between the bytes for ACK and NACK (?). From a terminal you should be able to detect it with i2cdetect and read it with i2cdump 1 7 35. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Also check this out: it seems to have everything except how to make a pd external from it. http://www.instructables.com/id/Raspberry-Pi-I2C-Python/ Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-07 04:30, Julian Brooks wrote: ... Also got a voltage transformer that works with i2c as the rpi is 3.5v and sensors 5v. You can use the 5V from the GPIO header on the pi. From the schematic pin 2 is 5V. Ground is on pin 6. Pin 3 is the i2c data and pin 5 is the clock. Pullup resistors are already installed on those lines. ... We have 2 sensors so we need to figure out how to set the 7bit addresses. Also that the data bit width is 8 - so I'm confused as to what the 35 bytes are and where they come from? You can't set the addresses. The only way to have two devices with the same address would be to gate the clock using another GPIO pin to control a chip like the CD4051 analog multiplexer so that only one of the sensors receives the clock signal. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-04-07 17:42, Julian Brooks wrote: Thanks Martin, really useful stuff. I've got i2cdetect on the RPi which is how I knew that [gpio] was setting hi lo. And good to hear you'll be wrestling with this on the Pi as well. In some ways this is good news as we've setup everything from the 'instructables' page already and now just need to get the bloody thing going (have to to sort the housings out). Another possible issue is that from my reading it seems that the RPi doesn't do 'clock-stretching', though I have found a link where they slow the i2c bus down. http://www.hobbytronics.co.uk/raspberry-pi-i2c-clock-stretching Another one here too: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44t=34734p=294297hilit=i2c+gpio+direction#p294297 That's interesting as they talk about setting up more GPIO pins for i2c to run 2 sensors. Not being able to change the sensors address is a real pain though, as one of the things that I keep reading about i2c is it's ability to run up to 128 sensors on the same line - kinda defeats the object! Must be a way round it. Maybe there's a way to program the address but so far its a secret known only to Omron. You can use the 5V from the GPIO header on the pi. From the schematic pin 2 is 5V. Ground is on pin 6. Pin 3 is the i2c data and pin 5 is the clock. Pullup resistors are already installed on those lines. Yes, found a good diagram for the GPIO schematic. http://elinux.org/RPi_Low-level_peripherals#GPIO_hardware_hacking My understanding was that what we can't do is send data from the sensor at 5v back into the RPi at 3.5v and it's there that we need to drop the voltage back to 3.5. Noticeably though the 'instructables' link says they just did it anyway and was fine (with a disclaimer attached on to it). The schematic for the RPi shows the resistors already installed, you don't need to add any. The resistors pull the bus voltage up to 3.3V when nothing is driving it to ground. Nobody is sending 5V signals, the i2c bus is either driven (clamped to 0V) or not driven, in which case the resistors bring the voltage to 3.3V, which is high enough for the 5V sensor inputs to read as 1. We got some 4.7k resistors as you recommended - do we only need these before the sensors? The pdf from digikey has a diagram with a voltage transformer that we've been presuming is what we need to do?? Presumably if we put more resistors next to the Pi then we wont have enough voltage to lift the pin high (many ???). There's also lots of code (C?) on that pdf, anything you've made use of? Yes that's what I got the crc calculation from, but as I said it doesn't give me the right result :( This is the little add-on board http://adafruit.com/products/757 I did read it's doable with mos-fet but seemed like another layer where we can screw-up so have taken the simple option. Yes you don't need any level shifter, the pullup resistors are enough, both 3.3V and 5V systems use the same voltage for 0. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-03-27 18:31, Martin Peach wrote: On 2013-03-27 17:17, Julian Brooks wrote: Hey Martin, Good to hear you've got one of these too. Yes I meant [comport] with the xbee rather than [hid] sorry, getting my physical input objects confused. Will check out the links you provided as part of my getting up to speed. So, managed to get the sensors out of the cardboard box. They are tiny. Like little sci-fi robot eyes. 1st problem is that we don't have any of these: 'JST (Japan Solderless Terminals) - PHR-4 - Housing, 4way, 2mm http://uk.farnell.com/jst-japan-solderless-terminals/phr-4/housing-4way-2mm/dp/3616204 Which is a vital £0.04.6 of equipment as the sensors pins are way too tiny to be poking bits of wire into. These attach to the bottom of the board and then 2mm cabling attaches to them and out to the Pi. Got some off ebay as farnell has a £20 minimum spend that's a bit over getting 10 of those suckers. So going to have to wait a few more days as I can't find any in my vicinity at all. Bollocks. Yes I got mine at Digikey. You need the terminals as well as the housings. I crimped the terminals to some 28 gauge wire and also put a bit of solder but not too much to plug them up. Today I managed to get data using an Arduino and the Wire library, with 4.7k pullup resistors on the clock and data lines. The packets are only 32 bytes, not 35 as the app note says. Not sure what's up with that. I changed the default buffer size in Arduino's wire library from 32 and now I get 35 bytes as advertised. The crc calculation is not giving me the right answer but that doesn't seem to matter. I get 16 pixels of temperature, it's detecting warm as well as cold objects, quite a nifty sensor! Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
On 2013-03-27 06:31, Julian Brooks wrote: Hi all, We've been after some sensors for motion detection on the RPi and Martin Peach spotted these (thanks again Martin!) http://uk.farnell.com/omron-electronic-components/d6t-44l-06/sensor-thermal-mems-4x4/dp/2218000 They're fairly new and I've not been able to find anything about anyone making use of them on the RPi as of yet (though after posting a question on the RPi forum I did note that Farnells stock went from 48 the 4 in three days, so maybe something soon eh?:). I've got absolutely no idea what I'm doing with this so could do with some 'hand-holding'. What I would much prefer would be to keep everything within Pd if possible... 1st off, and possibly dumb question - do we need [hid]? - My previous experience with xbee sensors did, so this is why I'm asking. [hid] is for USB devices so no. There are a few mentions of using python to get the data received on the Pi and then OSC'ing that into Pd but Miller mentioned on another thread gpio on the raspberry pi from within pd ? about writing an external to keep it within Pd. Any news/progress/tips on that front? http://www.gigamegablog.com/2012/11/04/beaglebone-coding-101-i2c/ talks about using i2c and python with the beaglebone which is a similar machine. It even uses code written for the Pi (https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code). Using python ans OSC seems to be the easiest way to get started. In the same thread Charles Goyard seems to have it working with [textfile], which seems far too simple (I'd very much like that if that was the case) The sensor transmits the data as i2c but I haven't found anything in the archives particularly about anyone translating i2c directly in Pd yet? I just got one of these and I'm going to try it with an arduino since the i2c there is easier to use. The arduino can talk to Pd using [comport]. Martin We're going to fire the sensors up and see what happens in an hour or so and then come back to it tonight for a proper session so any and all pointers gratefully accepted. I'll be back to let you know our 1st results soon. Cheers, Julian ___ 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] Sensors GPIO Raspberry Pi Pd
On 2013-03-27 17:17, Julian Brooks wrote: Hey Martin, Good to hear you've got one of these too. Yes I meant [comport] with the xbee rather than [hid] sorry, getting my physical input objects confused. Will check out the links you provided as part of my getting up to speed. So, managed to get the sensors out of the cardboard box. They are tiny. Like little sci-fi robot eyes. 1st problem is that we don't have any of these: 'JST (Japan Solderless Terminals) - PHR-4 - Housing, 4way, 2mm http://uk.farnell.com/jst-japan-solderless-terminals/phr-4/housing-4way-2mm/dp/3616204 Which is a vital £0.04.6 of equipment as the sensors pins are way too tiny to be poking bits of wire into. These attach to the bottom of the board and then 2mm cabling attaches to them and out to the Pi. Got some off ebay as farnell has a £20 minimum spend that's a bit over getting 10 of those suckers. So going to have to wait a few more days as I can't find any in my vicinity at all. Bollocks. Yes I got mine at Digikey. You need the terminals as well as the housings. I crimped the terminals to some 28 gauge wire and also put a bit of solder but not too much to plug them up. Today I managed to get data using an Arduino and the Wire library, with 4.7k pullup resistors on the clock and data lines. The packets are only 32 bytes, not 35 as the app note says. Not sure what's up with that. You write the value 0x4C (76) to address 7 and then request 32 bytes, which are 16 little-endian integers. The numbers are in tenths of a degree Celsius. I needed a 1 or 2ms delay between sending the command and requesting the data or the sensor would stop responding after 3 packets. Martin We did put our pi prototype/breadboard together though: http://www.coolcomponents.co.uk/catalog/raspberry-proto-plate-p-1104.html which will be useful for experimenting. Off to gen up on i2c, python and other such things I currently know nothing about. Back soon with further info. Cheers, Julian ___ 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] TCP/IP communication from the unix server to the Pure Data
OK, I added two externals into svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeach/serializer/
[b2f] will take four bytes and return a float, while [f2b] takes a float
and outputs four bytes. (This is really easy in c...)
Of course it only works if the floating-point format is the same at both
ends.
Martin
On 2013-03-14 13:41, Petar Jercic wrote:
Martin , thank you for everything, I got it working now even with
floating point numbers, here is the rundown of the method
[solved]
BUT BEFORE FOLLOWING THIS, NOTE THAT FLOATING POINT NUMBER IS SOMETHING
THAT YOU DON'T WANT TO PARSE, IF YOU LIKE YOUR NERVES.
The first problem is
1. Error was in using on the server side an ntohl() on a float number,
which corrupts it heavily. Mark my words, ntohl() is an enemy of the float.
Just receive it reversed and manually work out the conversion, you HAVE
to do it manually anyways :P
2. Float is a complex standard, even more complex when Pure Data
converts everything to decimal partially per byte. Separate Mantissa,
Exponent and Sign using bitwise operators [][], and work out the
float conversion.
Follow this thread for Mantissa, that one is the hardest Convert
floating point number from binary to a decimal number
http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/
Good luck ^^
//Petar
On 13/3/13 1:51 PM, Martin Peach wrote:
I attached a patch that should reconstruct a long if it's bigendian,
although it doesn't give 100 for the sequence you provided...
The floating point numbers are more difficult, you need to separate
the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize that I was using the
wrong endian method on my UNIX server, it has to be ntohl(). Now I got
it correct, and I am receiving data (bytes) in the correct order.
*: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78
*
Sample data might be 2 100 51 2000.56, which could be read in the
data ... somewhat :)*
**Now my question is, how do I get four compact numbers to work with?*
Now I have a series of bytes, but at least in the correct order.
I haven't been able to extract the data using [bytes2any] and [route],
so I prepared a small patch to demonstrate the problem, maybe you can
show me by modifying it?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to
send large quantities of data at high speed rates, I need to
optimize it
as much as possible. Compared to streaming bytes, ASCII is inefficient
up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C
functions:
ntohs()--Network to Host Short
ntohl()--Network to Host Long
You can do that with Pd like this (ntohs):
[unpack 0 0]
| |
[* 256]|
| |
[+ ]
|
[ \
or
[unpack 0 0]
| |
| [* 256]
| |
[+ ]
|
[ \
for littleendian.
Floats are harder but still possible. The main difficulty is in
splitting the incoming stream in the right places. (I think ASCII is
not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII
text, to avoid disagreements about endianness and floating-point
representation.
Then, to extract the numbers, you could use [moocow/bytes2any] or
make
a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing
else
than ; delimited messages.
So the solution for the problem:
*My question is, is there a way to send something other than string
message to Pure Data, like byte-stream or serialized number stream?
Can
Pure Data receive such messages?*
The solution is to use [tcpclient], it can receive byte-stream data.
Now I have another problem regarding the data read, on how to
convert it
back to usable numbers.
From my UNIX server I am sending a structure
typedef struct {
int var_code;
intsample_time;
int hr;
floaths;
} phy_data;
Sample data might be 2 100 51 2000.56
When received and printed in Pure Data I get output like this:
: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
You can notice number 2 and number 51 clearly, I guess the others
are
correct as well. Might be some network inversion of LSB/MSB.
*How can I get these numbers back to a usable format and get them in
separate variables?
*//Petar*
*
___
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
Re: [PD] TCP/IP communication from the unix server to the Pure Data
I attached a patch that should reconstruct a long if it's bigendian,
although it doesn't give 100 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the
sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize that I was using the
wrong endian method on my UNIX server, it has to be ntohl(). Now I got
it correct, and I am receiving data (bytes) in the correct order.
*: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78
*
Sample data might be 2 100 51 2000.56, which could be read in the
data ... somewhat :)*
**Now my question is, how do I get four compact numbers to work with?*
Now I have a series of bytes, but at least in the correct order.
I haven't been able to extract the data using [bytes2any] and [route],
so I prepared a small patch to demonstrate the problem, maybe you can
show me by modifying it?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to
send large quantities of data at high speed rates, I need to optimize it
as much as possible. Compared to streaming bytes, ASCII is inefficient
up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C
functions:
ntohs()--Network to Host Short
ntohl()--Network to Host Long
You can do that with Pd like this (ntohs):
[unpack 0 0]
| |
[* 256]|
| |
[+ ]
|
[ \
or
[unpack 0 0]
| |
| [* 256]
| |
[+ ]
|
[ \
for littleendian.
Floats are harder but still possible. The main difficulty is in
splitting the incoming stream in the right places. (I think ASCII is
not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII
text, to avoid disagreements about endianness and floating-point
representation.
Then, to extract the numbers, you could use [moocow/bytes2any] or make
a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing
else
than ; delimited messages.
So the solution for the problem:
*My question is, is there a way to send something other than string
message to Pure Data, like byte-stream or serialized number stream?
Can
Pure Data receive such messages?*
The solution is to use [tcpclient], it can receive byte-stream data.
Now I have another problem regarding the data read, on how to
convert it
back to usable numbers.
From my UNIX server I am sending a structure
typedef struct {
int var_code;
intsample_time;
int hr;
floaths;
} phy_data;
Sample data might be 2 100 51 2000.56
When received and printed in Pure Data I get output like this:
: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
You can notice number 2 and number 51 clearly, I guess the others are
correct as well. Might be some network inversion of LSB/MSB.
*How can I get these numbers back to a usable format and get them in
separate variables?
*//Petar*
*
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
#N canvas 596 245 450 277 10;
#X obj -13 59 unpack 0 0 0 0;
#X obj 14 149 * 65536;
#X obj 41 101 * 256;
#X obj -13 202 * 1.67772e+007;
#X obj 41 123 +;
#X obj 14 175 +;
#X obj -13 230 +;
#X floatatom -13 254 12 0 0 0 - - -;
#X msg -13 21 0 10 114 26;
#X msg 109 17 0 0 0 2;
#X msg 176 17 0 0 0 51;
#X connect 0 0 3 0;
#X connect 0 1 1 0;
#X connect 0 2 2 0;
#X connect 0 3 4 1;
#X connect 1 0 5 0;
#X connect 2 0 4 0;
#X connect 3 0 6 0;
#X connect 4 0 5 1;
#X connect 5 0 6 1;
#X connect 6 0 7 0;
#X connect 8 0 0 0;
#X connect 9 0 0 0;
#X connect 10 0 0 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Ultrasonic Range Finder
On 2013-03-12 08:58, Julian Brooks wrote: Hi, I'm after some advice: For an installation piece I'd like to do I'm investigating range finder sensors (for outdoors). Has anyone experience of the Maxbotic URF's and any tips they'd like to share for getting the data into Pd? I connect them to the analog inputs of an Arduino and send the data to Pd which reads it using [comport]. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Ultrasonic Range Finder
On 2013-03-12 09:32, Julian Brooks wrote: Hi Martin, Is this with Maxbotic and if so which one? I'm going to be running the sensor with an RPi as standalone so presume it's a similar setup (I believe comport runs fine on RPi) I use the MB1010 (MaxSonarEZ1). The analog output is very low level and also quite noisy, so a RC filter would be a good idea. The serial output is RS232 on 0-5V, so you need to invert it before reading it with a microcontroller USART input. The format is ASCII but it should be readable in Pd: from the output of [comport] you need to make lists of 4 characters starting with 'R' and convert the last three digits to a single float. That actually looks more reliable than the analog but I haven't tried it. I attached a patch to do that. With the Pi you probably need to watch out for voltages above 3.3V on the IO pins. Martin Would you mind letting me have a look at a patch for translating the input data (if you use/need one). I know from utilising xbees that the input data was tricky to parse - to me anyway. Cheers, Julian On 12 March 2013 13:23, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2013-03-12 08:58, Julian Brooks wrote: Hi, I'm after some advice: For an installation piece I'd like to do I'm investigating range finder sensors (for outdoors). Has anyone experience of the Maxbotic URF's and any tips they'd like to share for getting the data into Pd? I connect them to the analog inputs of an Arduino and send the data to Pd which reads it using [comport]. Martin #N canvas 57 434 568 394 10; #X text 191 61 -packet starts with the letter 'R'; #X msg 139 88 0; #X obj 112 117 f 0; #X obj 112 12 inlet; #X obj 143 117 + 1; #X obj 112 142 pack 0 0; #X text 173 144 - prefix each character with its index; #X obj 112 168 route 0 1 2 3; #X obj 130 206 - 48; #X obj 170 206 - 48; #X obj 210 206 - 48; #X obj 130 241 * 100; #X obj 170 241 * 10; #X obj 170 313 +; #X obj 155 333 +; #X obj 155 357 outlet; #X text 247 206 - convert ASCII digit to integer; #X text 215 264 - combine the decimal digits; #X obj 139 63 route 82; #X obj 112 37 t b f; #X text 112 -7 unpacks a stream of characters from a maxbotix sonar sensor; #X text 368 342 Martin Peach 2013_03_12; #X connect 1 0 2 1; #X connect 2 0 5 0; #X connect 2 0 4 0; #X connect 3 0 19 0; #X connect 4 0 2 1; #X connect 5 0 7 0; #X connect 7 1 8 0; #X connect 7 2 9 0; #X connect 7 3 10 0; #X connect 8 0 11 0; #X connect 9 0 12 0; #X connect 10 0 14 0; #X connect 11 0 13 1; #X connect 12 0 13 0; #X connect 13 0 14 1; #X connect 14 0 15 0; #X connect 18 0 1 0; #X connect 18 1 5 1; #X connect 19 0 2 0; #X connect 19 1 18 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] TCP/IP communication from the unix server to the Pure Data
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to
send large quantities of data at high speed rates, I need to optimize it
as much as possible. Compared to streaming bytes, ASCII is inefficient
up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C
functions:
ntohs()--Network to Host Short
ntohl()--Network to Host Long
You can do that with Pd like this (ntohs):
[unpack 0 0]
| |
[* 256]|
| |
[+ ]
|
[ \
or
[unpack 0 0]
| |
| [* 256]
| |
[+ ]
|
[ \
for littleendian.
Floats are harder but still possible. The main difficulty is in
splitting the incoming stream in the right places. (I think ASCII is not
orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII
text, to avoid disagreements about endianness and floating-point
representation.
Then, to extract the numbers, you could use [moocow/bytes2any] or make
a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else
than ; delimited messages.
So the solution for the problem:
*My question is, is there a way to send something other than string
message to Pure Data, like byte-stream or serialized number stream? Can
Pure Data receive such messages?*
The solution is to use [tcpclient], it can receive byte-stream data.
Now I have another problem regarding the data read, on how to convert it
back to usable numbers.
From my UNIX server I am sending a structure
typedef struct {
int var_code;
intsample_time;
int hr;
floaths;
} phy_data;
Sample data might be 2 100 51 2000.56
When received and printed in Pure Data I get output like this:
: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
You can notice number 2 and number 51 clearly, I guess the others are
correct as well. Might be some network inversion of LSB/MSB.
*How can I get these numbers back to a usable format and get them in
separate variables?
*//Petar*
*
___
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] TCP/IP communication from the unix server to the Pure Data
It's probably safer to get the server to send the numbers as ASCII text,
to avoid disagreements about endianness and floating-point representation.
Then, to extract the numbers, you could use [moocow/bytes2any] or make a
custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else
than ; delimited messages.
So the solution for the problem:
*My question is, is there a way to send something other than string
message to Pure Data, like byte-stream or serialized number stream? Can
Pure Data receive such messages?*
The solution is to use [tcpclient], it can receive byte-stream data.
Now I have another problem regarding the data read, on how to convert it
back to usable numbers.
From my UNIX server I am sending a structure
typedef struct {
int var_code;
intsample_time;
int hr;
floaths;
} phy_data;
Sample data might be 2 100 51 2000.56
When received and printed in Pure Data I get output like this:
: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
You can notice number 2 and number 51 clearly, I guess the others are
correct as well. Might be some network inversion of LSB/MSB.
*How can I get these numbers back to a usable format and get them in
separate variables?
*//Petar*
*
___
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] measuring entropy of a signal?
Why not do an FFT and measure the variance of the channels? For instance white noise has maximum entropy and all the bins of its FFT will be more or less the same, while a sine wave has low entropy and one bin will be much larger than the others. Martin On 2013-02-27 08:40, ronni montoya wrote: Hi, why is not possible? Instead of analysing the real time value of the signal , maybe i can have a memory or buffer that store the a piece of signal ( groups of samples) from time to time and then analize that group of values. Maybe it can convert that group of values into a string and then: http://www.shannonentropy.netmark.pl/calculate Other idea : ive seen using shannon entropy for calculating complexity in terms of spatial configuration. Maybe other option could be converting my signal into image for example using similarity matrix and then analyze that image to get entropy values. cheers R 2013/2/26, Charles Z Henry czhe...@gmail.com: Hi Ronni How do you mean to do it? Shannon entropy is not an independent measurement--the information in a observation is relative to the distribution of all it's possible values. If I just take one sample and it's evenly distributed between -0.98 and 1 and it's quantized in 0.02 increments (to make the math easier), then the information of any value observed is: -0.01*log(0.01) Then--if I had a signal that's N samples long, I have N times as much information. Or perhaps think of it as a rate of information. But for real numbers and continuous distributions, this doesn't work. The information in a single observation diverges. So, doing that with floating point numbers is not practical. You often see Shannon entropy describing digital signals. If the signal just switches between 0 and 1, we can generate a distribution of the data and see what the probability is empirically. The entropy of each new sample is relative to the distribution. Likewise, then if you know the maximum rate of switching, you can figure out the maximum rate of information in the signal. Just a few thoughts... Chuck On Tue, Feb 26, 2013 at 6:09 AM, ronni montoya ronni.mont...@gmail.comwrote: Hi , i was wondering if anybody have implemented the shannon entropy function in pd? Do anybody have tried measuring entropy of a signal? cheeers R. ___ 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
Re: [PD] Solution for deleting files via pd?
On 2013-01-27 16:25, Sebastian Valenzuela wrote:
Hi list,
My Pd patch creates and saves new audio files to a designated folder on
my desktop. I would like to have Pd delete these files every time I open
my patch ([loadbang]).
I've heard the [shell] object is a possibility, but i'm not too keen on
terminal commands or how they will pertain to [shell]...
Can anyone please give me an example of a command I would send to
[shell] to delete all files within a specified folder on my desktop? If
this isn't the best way to do it, is there another possibility through Pd?
You can use pdlua for this kind of thing.
See the attached patch. Right-click inside the [deletefile] object to
open deletefile.pdlua in an editor.
Martin
#N canvas 398 519 752 300 10;
#X obj 153 109 deletefile;
#X msg 153 64 delete /home/martin/pd_patches/test.xxx;
#X obj 153 143 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X text 175 142 outputs 1 on success;
#X connect 0 0 2 0;
#X connect 1 0 0 0;
--[[
--deletefile
-- Symbol input is name of file to delete
-- Martin Peach 20130127
--]]
-- Pd class
local deletefile = pd.Class:new():register(deletefile)
function deletefile:initialize(name, atoms)
self.inlets = 1
self.outlets = 1
return true
end
function deletefile:in_1_delete(atom)
pd.post(type(atom[1]))
if type(atom[1])==string then
--self:outlet(1, symbol, {atom[1]})
f = io.open(atom[1], r)
if (f == nil) then
pd.post(can't open .. atom[1])
else
pd.post(deleting .. atom[1])
result = os.remove(atom[1])
if (result) then q = 1
else
q = 0
end
self:outlet(1, float, {q})
end
else
pd.post(need a file name)
end
end
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever? Martin On 2013-01-21 15:11, Leandro da Mota Damasceno wrote: so let's see...Who´s working with what so far? I´d love to join a team and start learning how to code with one of the toolkits. On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need. .hc On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: You're right. Damn, you're always right :) So, just to know where we are right now... What have been tested/done regarding the GUIs toolkits so far? I think we should at least have this set and go on from there... On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.atwrote: I think this is the general idea of what everyone wants to support. But the way is actually takes shape is going to depend on whoever actually does the work. A great example of this is the PDDP (Pure Data Documentation Project). We had lots of design meetings and then no one implemented the ideas. Then Jonathan picked up from that what was interesting to him and made the whole meta help system, the search plugin, etc. The lesson there for me is that big design discussions only work if the people involved them are willing to do the work to implement them. Instead, I think for a more decentralized community like this one, we only should nail down the key parts that everyone must use, then leave other decisions to those who are implementing those parts. So that means I'm happy to help people write there own GUI, and I'll definitely be involved in the work of making it possible with Pd. .hc On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: That sounded like a Lego approach. :) So the way I see it the GUI development should be in the most seemless way for the user, right? And we also have the problem between people who prefer a simple, leaner GUI approach (the classic PD, for instance) against people who prefer a more sofisticated, and sexy GUI. And I believe both groups would also like some more knobs and stuff... so basically, we should at least have two options of gui: simple (classic) or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to work (and now I must admit I really don't know the architecture behind this part of PD, so maybe it is already this way), the comunication between the GUI and the rest of PD should be kept simple, fast and modulated, working with the leanest possible API. I also think this is a good approach considering that most of these toolkits will stop getting support way before PD ceases to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance... At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the other at the core PD end... What do you guys think? On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: - Original Message - From: Billy Stiltner billy.stilt...@gmail.com mailto:billy.stilt...@gmail.com To: IOhannes zmölnig zmoel...@iem.at mailto:zmoel...@iem.at Cc: pd-list@iem.at mailto:pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near
Re: [PD] changing timestamp of noteout midi message
There is no timestamp in the MIDI spec. A noteout message sends three bytes: status+channel, number, velocity. Martin On 2013-01-15 08:02, Panagiotis Melidis wrote: as it seems the problem would be solved if i could find a way to add a timestamp each time noteout sends a message... but is there a way to do that? should i modify the noteout source code? is there maybe another way to send timestamped midi messages from pure data? thanks again! = Panagiotis Melidis http://www.larrygus.com http://facebook.com/larrygus http://twitter.com/larrygus http://larrygus.tumblr.com On Tue, Jan 15, 2013 at 1:21 PM, Panagiotis Melidis pmeli...@gmail.com mailto:pmeli...@gmail.com wrote: hey people! i am working on osx, ver 10.8.2 i am sending noteout messages from PD over to Ableton Live via the IAC driver, but after a certain point ableton live ignores the messages, and this has to do with the fact that live itself is getting confused by the timestamps. on the ableton forums people found that the solution is to add the timestamp with the midi message, and some people managed to achieve it for C++ and Python as explained in those two posts; https://forum.ableton.com/viewtopic.php?p=1426466#p1426466 https://forum.ableton.com/viewtopic.php?p=1347051#p1347051 so, i am struggling to find a way to change the timestamp of a noteout message but i can't do it. any ideas? hope i was clear enough :) = Panagiotis Melidis http://www.larrygus.com http://facebook.com/larrygus http://twitter.com/larrygus http://larrygus.tumblr.com ___ 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] libPd PdDroidParty comport ?
On 2013-01-06 15:13, Maurin Donneaud wrote: Im trying to connect Arduino via bluetooth to libPd / PdDroidParty running on my android. Does the comport could be used for that communication ? Do anyone already try this combination? If you give the [devices( message to [comport] you will get a list of available ports in the Pd window. A bluetooth port will be one of the ports in the list, you can select it by name like [ devicename /dev/ttyS21 ( or by number as [ open 21 (. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] translate the Start Here! page
On 2013-01-05 22:36, Hans-Christoph Steiner wrote: On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote: - Original Message - From: Ed Kelly morph_2...@yahoo.co.uk To: Jonathan Wilkes jancs...@yahoo.com; Hans-Christoph Steiner h...@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page OK, no need to fight. This is about a version of Pd-extended that has been a very long time coming, that had many issues to resolve, that went offline and was unavailable at the start of the workshops I teach. I also can't get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of programming. They'll give up straight away! Of course. I'm just giving you a beginner's perspective; it's my own memory of that perspective that drives me to work on tools which are currently only marginally useful to me personally. The supermajority of discontent among your students tells me that this perspective hasn't changed much. By far, that is currently the fault of the software-- the documentation is currently too slim and core pd building blocks (and interface) too crude for the question how do I find more objects to be anything like an ancillary question. A static out-of-date list is better than nothing, but as far as potential dev energy I'd really rather see that put into core docs like the ones listed on the bug tracker, which are extremely lacking. That FLOSS list will hopefully become obsolete, but the help docs won't-- even if they're dropped from Pd-extended they're still publicly available. -Jonathan While I have agreed and disagreed with various points in this discussion, I think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META]. Yeah, and we need the spec for [Pd META] to be known. For devs maybe en entry in the externals HOWTO? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] comport questions
On 2012-12-03 13:45, Pagano, Patrick wrote: Does not work either. Are you using the right cable? Does it work with any other program? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] comport questions
On 2012-12-03 14:41, Pagano, Patrick wrote: I tried with two separate cables, to make sure One was a gigaware usb-A-serial cable 26-949, the other was a simple dongle one that windows 7 setup automatically I have even hooked it up to an XP box that had 2 dedicated serial ports, changed the serial cable extension just in case Still with no response I am at a loss Currently it's hooked up to a windows XP box running pd-extended 42-5 and hooked directly from the serial port to the BenQ projector The port was previously hooked up and working with a gentner echo suppressor so I know it works I would check to see if the cable is a modem or a printer cable (does it cross over Rx - Tx or not?). Also handshaking may be required (RTS/CTS or DSR/DTR). Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Browse/Search plugin update
On 2012-12-01 13:50, Jonathan Wilkes wrote: Added a little documentation on puredata.info: https://puredata.info/Members/jancsika/helpbrowser2.0/ -Jonathan That's nice but you still don't say how to install it. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Browse/Search plugin update
On 2012-12-01 15:40, Jonathan Wilkes wrote: From: Martin Peach martin.pe...@sympatico.ca To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Saturday, December 1, 2012 2:36 PM Subject: Re: [PD] Browse/Search plugin update On 2012-12-01 13:50, Jonathan Wilkes wrote: Added a little documentation on puredata.info: https://puredata.info/Members/jancsika/helpbrowser2.0/ -Jonathan That's nice but you still don't say how to install it. Martin Ok, have a look now. I added a link at the bottom of the page to the gui-plugin doc. OK thanks, I had assumed it was meant to go in pd/tcl (in fact it did work from that location without me having to set any paths). Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] can i bypass comport?
Better to use [tcpclient] / [tcpserver] or [udpreceive] / [udpsend]. A single [tcpserver] or [tcpclient] can send and receive. Martin On 2012-11-30 16:45, o...@onyx-ashanti.com wrote: Ok, so i got the [tcpsend]to work. i connected it at the point where the comport would usually get info. it is connected to the ip xxx.xxx.xxx.xxx 3000 and when i turn the patch on, it sends the appropriate data to the arduino fio/rn-xv over wifi. the problem now is that the [tcpreceive 3000] isnt receiving anything. from what i have read, tcpsen and tcp recieve work on the same port so if that port is an ip address, what would be the prefered means of getting the data from the fio? I am experimenting with port forwarding on my router right now. Is there anything you might know of that i could/should try, that might sort the port conflict out? cheers, Onyx On Mon, Nov 26, 2012 at 4:33 PM, o...@onyx-ashanti.com mailto:o...@onyx-ashanti.com onyxasha...@gmail.com mailto:onyxasha...@gmail.com wrote: I am going to investigate the updated wifly, wiflyserial and ethernet libraries onto the sketch for the rn-xv/arduino. this should allow me create a serial socket or something, once i grasp all that stuff a bit better. tcpclient, in place of [comport] connects and shows data sent but nothing is happening in pd or the arduino fio. i have begun toying with udpsend/udprecieve but that isnt working because i am sure that i havent connected the i/o in a manner that provides [comport] replacement functionality. i should have some results from that shortly. from what i have read, the way udp works might be better and if i can get one of the above libraries to see it, maybe my problem will be solved. i will let you what i come with in a few hours On Sun, Nov 25, 2012 at 10:59 PM, Martin Peach martin.pe...@sympatico.ca mailto:martin.pe...@sympatico.ca wrote: On 2012-11-25 15:51, o...@onyx-ashanti.com mailto:o...@onyx-ashanti.com wrote: if comport could accept an ip port argument, as well as a serial port argument, all would be lovely and nothing would have to change. it would simply recieve itsport from the ip. is there anything like this? In pd-extended there are [udpsend] and [udpreceive] as well as [tcpclient] and [tcpserver] that can be used instead of [comport]. Probably you'll need to add a [import net] to get them. Martin -- www.onyx-ashanti.com http://www.onyx-ashanti.com -- www.onyx-ashanti.com http://www.onyx-ashanti.com ___ 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] comport questions
On 2012-11-29 11:49, Pagano, Patrick wrote: Hello I have now tried with a projection Design f1 projector and I still cannot get comport to talk to the projector I can open the port, I see the device, it accepts settings but when I send the ascii it still has no effect. The f1 command is :POWR1'CR' [58 80 79 87 49 13[ should be [58 80 79 87 82 49 13] Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] comport questions
It should work. You could try using a terminal program to manually connect. From skimming the manual for that projector it says the RS-232 is for firmware upgrades only... Martin On 2012-11-28 14:34, Pagano, Patrick wrote: Hi With the recent talk about comport I have tried to use it to control a BenQ MX660P Projector and I am having no response from the machine. RS-232 protocol Baud Rate 115200 bps (default) Changeable(2400/4800/9600/14400/19200/38400/57600/115200) Setting in OSD menu Data Length 8 bit Parity Check None Stop Bit 1 bit The command to turn it on is: CR*pow=on#CR But I am getting no response from the machine. I am using the ascii list of bites to send the message, maybe this is incorrect? Perhaps someone may shed some light upon this for me? I am on Windows7, pd 42-5 extended Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2020 ___ 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] comport questions
On 2012-11-28 17:16, Pagano, Patrick wrote: The benq tech says it should work for commands. I am going to try with another projector, but I can't believe they would put in an rs232 port only for firmware upgrades? Dunno. where did you get the command list from? (Stuff like CR*pow=on#CR) Martin On Nov 28, 2012, at 3:47 PM, Martin Peach martin.pe...@sympatico.ca wrote: It should work. You could try using a terminal program to manually connect. From skimming the manual for that projector it says the RS-232 is for firmware upgrades only... Martin On 2012-11-28 14:34, Pagano, Patrick wrote: Hi With the recent talk about comport I have tried to use it to control a BenQ MX660P Projector and I am having no response from the machine. RS-232 protocol Baud Rate 115200 bps (default) Changeable(2400/4800/9600/14400/19200/38400/57600/115200) Setting in OSD menu Data Length 8 bit Parity Check None Stop Bit 1 bit The command to turn it on is: CR*pow=on#CR But I am getting no response from the machine. I am using the ascii list of bites to send the message, maybe this is incorrect? Perhaps someone may shed some light upon this for me? I am on Windows7, pd 42-5 extended Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2020 ___ 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
Re: [PD] comport questions
On 2012-11-28 18:41, Pagano, Patrick wrote: Benq says the rs232 is for control this is from the manual Type OperationASCII Write /Power On/ CR*pow=on#CR Could the Type? Be preventing it? I don't think so. I wonder if the character for CR is 13 or 10 (or both)? Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] can i bypass comport?
On 2012-11-25 06:43, o...@onyx-ashanti.com wrote:
Well no, the xbee is replacing the usb serial connection in that
design, but you still have to run at the speed of the xbee serial
connection. The arduino doesn't have enough memory to do TCP/IP
the rn-xv 's uart pors baudrate is running at 57600, so shouldnt that
corral the the connection to within useable range?
Depends what's useable for you I guess.
You just need to set the comport objects baud rate to 57600.
The RN-XV manual says: Valid settings are {2400, 4800, 9600, 19200,
38400, 57600, 115200, 230400, 460800, 921600}
So you could probably go faster than 57600, the arduino can do at least
115200.
Martin
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
