Re: [PD] Missing objects in Pd-Extended Intel OSX?
On 04/23/2013 02:26, Jonathan Wilkes wrote:
I cannot figure out where the code is,
externals/loaders/hexloader/
but I'm assuming there is a loop
that goes through each path in search of $object_name.$whatever to
load the setup routine, and then goes through each path for
$object_name.{pd, max} for loading abstractions.
yes kind of.
Is this the case? If so why not say for each directory, check if there
is a $directory-meta.pd, and if there is parse it to find a comment in the
form of:
ALIAS normal_characters_name weird_characters_name1 weird_characters_name2
etc.
sounds like a good idea, though
Then if $object_name matches any of the atoms that follow ALIAS, look for any
files inside
$directory that match any of the aliases. If you find a match, follow the
current loading logic
(i.e., look for $objectname_setup, etc.). This has the benefit that the
external/abstraction
developer doesn't have to care about what order to put the atoms after ALIAS,
only that
one of the atoms uses normal characters that correspond to the characters
of the filename
(minus the file extension) that contains the class/abstraction.
i'm pretty sure there is a catch somewhere when it comes to loading
abstractions.
Finally, if there was a match, and there was a $normal_characters_name_setup
that
was executed without error, then Pd should automatically do a
class_addcreator for
each of the remaining aliases.
not sure whether this should be handled automatically or explicitely
within an external.
I suppose its easier to require $1 of the ALIAS comment to be
normal_characters_name.
I think it's better for the external/abstraction author if it can be an
unordered list, but honestly
anything is better than the current hexloader complexity.
what's that complexity? having to have to look up some characters in
an ascii table?
If someone can explain to me where the loop is in the source code where Pd
looks for
binaries/abstractions, I'll try to code it myself.
just check the various loaders in externals/loaders/
gmdrs
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
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 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 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
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 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 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 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] Negative input numbers for [pow] return 0
Disclaimer: I don't feel too strongly about this because I realised my original calculation was wrong anyway, however... If you think about it negative exponents require a completely different algorithm that is discontinuous with the one for positives. Instead of multiplying you divide n times. For sure, but we're talking about negative bases, additionally negative exponents are already handled correctly by [pow]. bien sur, it would be easy to add this. the thing is, do we really want that? having NaN's somewhere in your computation will have all the results become NaN, including any signals. NaN-signals don't sound good. There are many things I can do in Pd that don't sound good, I've bust my ears and headphones/speakers too many times to know that :) I would argue that yes (I personally) would want that. If the calculation is wrong, then it's my fault. Also, this is in reference to a message object that's being used for a graph calculation. Receiving '0' was confusing. the output is a number of the value NaN (which gets displayed as NaN, but this doesn't mean it a symbol ,just like 1e-8 is not a symbol either...usually) Good to know, thanks! Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? Obviously [expr] is a good solution but still the fact that [pow] acts differently feels non-intuitive. Cheers, Joe On 22 April 2013 21:43, IOhannes zmölnig zmoel...@iem.at wrote: On 04/22/2013 04:07 PM, Joe White wrote: Would it be possible to add this to [pow] as well? Something like for negative base values, non-integer exponent values would return NaN? bien sur, it would be easy to add this. the thing is, do we really want that? having NaN's somewhere in your computation will have all the results become NaN, including any signals. NaN-signals don't sound good. Additionally for [pow] to output '0' seems wrong, because that is definitely not the answer. I've never seen NaN output elsewhere so I'm assuming [expr] outputs a symbol and not some Pd defined NaN type (maybe?). no. the output is a number of the value NaN (which gets displayed as NaN, but this doesn't mean it a symbol ,just like 1e-8 is not a symbol either...usually) fmgar IOhannes __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list -- Follow me on Twitter @diplojocus ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Sorry - meant to add this link from RPi forum about running 2 i2c busses: enable both i2c busses http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44t=33092p=336846#p336846 On 23 April 2013 10:06, Julian Brooks jbee...@gmail.com 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 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 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 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] Negative input numbers for [pow] return 0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD80 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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
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 That's a much better doc. 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. (did you spot my previous post with this and if so would that work?) 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 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'? Yes, it even works as an icecube detector! :D ___ 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
[PD] [PD-announce] Open Position for Medialab-Prado's Director
Madrid Arte y Cultura S.A (MACSA) announces a job opening for the new Medialab-Prado director. Complete description of the position available for download from: http://medialab-prado.es/article/macsa_director_medialab Candidates must send their applications, together with the required documentation, within a month from the day this announcement is published. -- Medialab-Prado Plaza de las Letras Calle Alameda, 15. 28014 Madrid difus...@medialab-prado.es http://www.facebook.com/MedialabPradoMadrid Twitter: @medialabprado "Antes de imprimir este documento asegrate de que es realmente necesario. Gracias por tu colaboracin!" ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Missing objects in Pd-Extended Intel OSX?
- Original Message - From: IOhannes m zmölnig zmoel...@iem.at To: pd-list@iem.at Cc: Sent: Tuesday, April 23, 2013 3:01 AM Subject: Re: [PD] Missing objects in Pd-Extended Intel OSX? On 04/23/2013 02:26, Jonathan Wilkes wrote: [...] Then if $object_name matches any of the atoms that follow ALIAS, look for any files inside $directory that match any of the aliases. If you find a match, follow the current loading logic (i.e., look for $objectname_setup, etc.). This has the benefit that the external/abstraction developer doesn't have to care about what order to put the atoms after ALIAS, only that one of the atoms uses normal characters that correspond to the characters of the filename (minus the file extension) that contains the class/abstraction. i'm pretty sure there is a catch somewhere when it comes to loading abstractions. Can you explain what the catch is? Is it intractable? Finally, if there was a match, and there was a $normal_characters_name_setup that was executed without error, then Pd should automatically do a class_addcreator for each of the remaining aliases. not sure whether this should be handled automatically or explicitely within an external. For [block~]/[switch~] level flexibility I think it has to be explicit. I need to think about it more... I suppose its easier to require $1 of the ALIAS comment to be normal_characters_name. I think it's better for the external/abstraction author if it can be an unordered list, but honestly anything is better than the current hexloader complexity. what's that complexity? having to have to look up some characters in an ascii table? Plus telling the user, To not get broken objects load this library that has a bug that is the reason it didn't already load. But yes, having to look up characters in a table or even notice them in a filename in the help browser or search plugin is more complex than looking at human readable filenames and/or _setup routines. If someone can explain to me where the loop is in the source code where Pd looks for binaries/abstractions, I'll try to code it myself. just check the various loaders in externals/loaders/ Ok thanks. -Jonathan gmdrs 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] Missing objects in Pd-Extended Intel OSX?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 18:30, Jonathan Wilkes wrote: i'm pretty sure there is a catch somewhere when it comes to loading abstractions. Can you explain what the catch is? Is it intractable? no. this was a generic i'm sure there is one but i cannot name it now message. mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2uO8ACgkQkX2Xpv6ydvQUAgCgj9c1ntBc8XAV1CqoScu9OgRV qSoAmwQn0TgEYeOQV73x74XcC9pNo8vL =KNyU -END PGP SIGNATURE- ___ 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 23 April 2013 14:45, Martin Peach martin.pe...@sympatico.ca wrote: Yes that would work too, if you can handle the soldering ;( Don't think I can tbh - Don't like soldering at the best of times and those teeny pins and housings almost drove us to despair. 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. Don't think this is possible with the rev1 board - I do have a rev2 so might have to jump ship, though my super minimal image has some networking issues - I can't get it to ssh and register on home network with fixed ip on rev2 (must be sortable). Another way would be to have the Pd patch request a reading from a specific sensor. Can we do that if they have the same address? I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup. Yep - it is very specific, bloody good tho'. Julian 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/1426182http://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/2212120http://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.pdfhttp://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 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.peach@**sympatico.ca 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
Re: [PD] Negative input numbers for [pow] return 0
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See: https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70 -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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] Negative input numbers for [pow] return 0
Yep. It's damaging to have NaN's propagating around in Pd. [pow] having a single output means that you only want real values. The result is not a real number-I think the result should just be set to 0 (perhaps 1 depending on what the worst usage case is). Would it be better to have pow just output the real part of the complex number, generated from: (-1*base)^exp*e^(pi*exp*i) Which is (-1*base)^exp*cos(pi*exp) when base is a negative number this assumes the standard branch cut in complex analysis: -1=e^(pi*i) and not e^(3*pi*i) or any other Chuck On Apr 23, 2013 9:11 PM, Ivica Ico Bukvic i...@vt.edu wrote: It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See: https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70 -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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] FW: Negative input numbers for [pow] return 0
Forgot to copy list. From: Ivica Ico Bukvic [mailto:i...@vt.edu] Sent: Tuesday, April 23, 2013 11:15 PM To: 'Charles Z Henry' Subject: RE: [PD] Negative input numbers for [pow] return 0 Yes, the proposed patch generates 0 when imaginary numbers are involved and issues warning on the console with ability to track the error. From: Charles Z Henry [mailto:czhe...@gmail.com] Sent: Tuesday, April 23, 2013 10:39 PM To: Ivica Ico Bukvic Cc: pd-list; IOhannes m zmoelnig Subject: Re: [PD] Negative input numbers for [pow] return 0 Yep. It's damaging to have NaN's propagating around in Pd. [pow] having a single output means that you only want real values. The result is not a real number-I think the result should just be set to 0 (perhaps 1 depending on what the worst usage case is). Would it be better to have pow just output the real part of the complex number, generated from: (-1*base)^exp*e^(pi*exp*i) Which is (-1*base)^exp*cos(pi*exp) when base is a negative number this assumes the standard branch cut in complex analysis: -1=e^(pi*i) and not e^(3*pi*i) or any other Chuck On Apr 23, 2013 9:11 PM, Ivica Ico Bukvic i...@vt.edu wrote: It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See: https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70 -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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
