Re: [PD] check mail with pd ?
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
Re: [PD] compiling Pd 0.45 on Linux
On 02/07/2014 06:06 PM, Max wrote: there is no binary in the bin directory after all this. any ideas? with autotools, the binary is called src/pd gmr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] some externals not found in new install of 0.43.4
Hello, I installed pd 0.43.4 (20121027) on a new mbp w/ OS X 10.8.5 and noticed that some but not all externals are not found. E.g. soundhack is ok, dfm1 is not found. I realised that I get it to work after entering an extra line specifically for the dfm1-external into the search paths. Why is that? Thanks, Michael. -- http://mz.klingt.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] some externals not found in new install of 0.43.4
or you can call externals by using [import ] i guess it is a good practice . 2014-02-08 10:24 GMT+01:00 Michael Zacherl sdiy-m...@blauwurf.info: Hello, I installed pd 0.43.4 (20121027) on a new mbp w/ OS X 10.8.5 and noticed that some but not all externals are not found. E.g. soundhack is ok, dfm1 is not found. I realised that I get it to work after entering an extra line specifically for the dfm1-external into the search paths. Why is that? Thanks, Michael. -- http://mz.klingt.org ___ 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] some externals not found in new install of 0.43.4
On 8 Feb, 2014, at 11:02 AM, Py Fave pyf...@gmail.com wrote: or you can call externals by using [import ] hm, Malte Steiner recommended that to me the other day, but what name to import? neither the file name nor the object name worked. i guess it is a good practice . 2014-02-08 10:24 GMT+01:00 Michael Zacherl sdiy-m...@blauwurf.info: Hello, I installed pd 0.43.4 (20121027) on a new mbp w/ OS X 10.8.5 and noticed that some but not all externals are not found. E.g. soundhack is ok, dfm1 is not found. I realised that I get it to work after entering an extra line specifically for the dfm1-external into the search paths. Why is that? Thanks, Michael. -- http://mz.klingt.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
Jonathan Wilkes wrote: On 02/06/2014 02:08 PM, Charles Goyard wrote: Hi, i go bananas wrote: In what way? that's what i want to know! If that's a general question, then the answer is yes, as you can get and send bytes over a network and do math with pd. It's also the answer for all general questions like can I do something a computer does with pd ? It does not mean it fits you needs, or the amount of work you want to put in :). Not giving contexts does not lead to useful answers. That's a self-fulfilling prophecy. You're right. Also maybe it's a bit rude, too. But I still find I'm right about giving context. While your answer IS instructive (thanks about that), not having context made you assume the question was about Bitcoin, which can be wrong, and makes your answer something specific about a possibly more general question, or about another cryptocurrency of some sort (I guess I'm nitpicking at bit on this one). That's why I asked about details and context. But yes, my message was not useful in itself, nor is this one :). Happy hacking in pd, -- Charles ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
maybe our own Pdcoin w/ mining ability only through/with Pd externals/patches m On Thu, Feb 6, 2014 at 4:09 AM, i go bananas hard@gmail.com wrote: Has anything been done to try to marry these together yet? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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] cryptocurrency and pd
I would be a little cautious about this. If you ended up implementing something that garnered wider interest, you'd raise the reward for attacks on normal Pd users and on Pd community infrastructure. That'd be a major burden for Pd users-- keeping an eye out for me.grimm@blah vs me.grim@blah, running patches in a virtual machine, having to learn GPG... That last one makes me shudder. -Jonathan On Saturday, February 8, 2014 10:38 AM, me.grimm megr...@gmail.com wrote: maybe our own Pdcoin w/ mining ability only through/with Pd externals/patches m On Thu, Feb 6, 2014 at 4:09 AM, i go bananas hard@gmail.com wrote: Has anything been done to try to marry these together yet? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.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] check mail with pd ?
On 02/08/2014 01:40 PM, Martin Peach wrote:
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.
It looks more like a prototype for a string implementation. I'm not
even able to do this:
[bng]
|
[str hello_world]
|
[print]
Additionally, moving the cord-inspector over the wire connecting
displays nothing. Those are just the first two things I tried to do as
a user, to view a core atom type which most of the time will be holding
readable text.
It may seem trivial to get those two things to work, but the point is
that someone has to do it, for every single internal and external class
which already understands and can manipulate the one string atom but
doesn't understand the better string atom.
[str hello 32 world] isn't much fun, either. But it's hard to improve
that without the ability for the object box to leave the user input
unparsed.
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.
I don't understand this. If you take nearly every string manipulation I
did in tcl for the search-plugin and put it in Pd, you are either a)
unrolling several commands in nested square brackets and laying them out
vertically (or inside an abstraction) or b) putting a tcl line of code
in a box and connecting its output to the next line of tcl code in a box
with a wire. If a is troublesome to patch and read in Pd then it was
hard to write and read in tcl.
There are of course way more complex examples of string manipulation,
but Pd's tools don't have to be perfect to be useful.
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.
Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word terrorism make a sound.
User takes a drink.
Totally useful. :)
What is it about boxes connected with lines that you think makes this
difficult?
-Jonathan
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
Re: [PD] check mail with pd ?
thanks frieds for direction. I did a patch . with pyext. and it works ! it does what i want: - check mail box with given subject - count mails with given subject BUT I cant have a trigger (bang) from that. it i strange. Even if my pyext object fills nbx with numbers, it won't give a bang. I think it is a bug. my situation is: [nbx] - with changing number of mails from pyext object (works ok) | | bang - BUT this bang never works. It is bug. or ? [archinux, pdextended 43.5] -- Fero Kiraly pianist, musician, teacher www.ferokiraly.com www.cluster-ensemble.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: 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. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word terrorism make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/08/2014 11:44 PM, Simon Wise wrote: On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: 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. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word terrorism make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. It sounds like you are rationalizing and encouraging non-development. But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text. -Jonathan Simon ___ 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
