Re: [PD] [OT] Voice Synth
moin Patrice, On 2007-06-08 17:21:48, patrice colet <[EMAIL PROTECTED]> appears to have written: > thank for making pd speak, I've successfully compiled [flite] for amd64 > on ubuntu feisty, but i had to hack the configure file, > the -fPIC flag was missing, so I've added this one at line 3845: > > WFLAGS="-Wall -fPIC" > > I didn't test if this code is compatible with other architectures, I'm > not an expert, :D. -fPIC should be linux-safe; I'm actually surprised it wasn't there already... at any rate, it's there now (in cvs): thanks for the report. just for the record, what happened when you tried to compile without -fPIC ? > It wasn't enough, [flite] dependances has been installed with apt-get, > then the flite headers and libraries wasn't in a place expected by the > configure file (I didn't have chace with --with-flite-dir option). I > didn't modify the configure file very elegantly for having the script > finding headers and libraries, but it has worked... > > IFLAGS="$IFLAGS -I/usr/include/flite" > LFLAGS="$LFLAGS -L/usr/lib" Funny, it works here (debian) with the deb-default flite (and -dev) locations... in such situations (i.e. "non-standard" prefab installation locations), the "official" solution for anything built with the gnu autotools (like flite or any other of my externals) is to set the environment variables such as CPPFLAGS (C preprocessor flags, *not* c-plus-plus flags), CFLAGS (C compiler flags), LDFLAGS (linker flags), LIBS (additional libraries) etc.; so you could do something like: $ export CPPFLAGS="-I/usr/include/flite" $ export LDFLAGS="-L/usr/lib" $ ./configure ; make ; make install ... and the build ought to work without having to hack the configure script. I think that this is a pretty good way to handle arbitrary installation locations & distribution foibles, so I do not plan on changing this behavior or the default locations. > The attached file is a modification of the help patch I've made for > resolving a buffer issue, I've just added a banged message > [;array const 0( > before flite computes the voice, for emptying the buffer, it's one > method among many others... what happens on your system if you don't explicitly zero the array before re-synthesis? > And finaly, anyone knows how to configure the synthetized voice? Basically: you can't do that with the pd [flite] object in its current form (sorry). It is (supposedly) possible, though: there is a bizarre and cryptic C-level flite API to allow tweaking of some of the many configuration parameters that festival offers, but I'm not a festival expert, I rather dislike SCHEME (give me LISP!), and trying to figure out which of festival's SCHEME-coded options got transmogrified into which of flite's C structures & parameters without sufficient documentation or examples is more than I felt like dealing with; I may get around to it some day, but it's not too high on my list of priorities as long as [flite] continues to block the cpu during synthesis. If you want/need user-configurable _offline_ synthesis, consider using festival directly (e.g. from pd with SayWhat over OSC). marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdstring feature requests...
moin, On 2007-07-25 15:29:28, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to have written: > during my recent work with pdstrings, 2 issues came upon me. > > [any2string]: this object usually terminates the output string with a 0 > (after all it is a somewhat arkward representation of a c-string). > it would be cool if one could change this, and make it configurable. > > currently i have to [list split] the string list before the last element > (using [list length]) and then [list append] CRLF. this seems a bit of > an overhead to me. i agree it would be nice. nonetheless, i'm hesitant to try and turn pdstring into an all-singing, all-dancing string handling mechanism for pd; it is (and always was) just an ugly hack. its only justification (to me) is that it *is* possible to use [list whatever] to manipulate the output atom-lists (at the time of pdstring's writing, i was using [drip], [glue], [length], and [niagara] ;-) > [string2any]: analogous to the above described behaviour, [string2any] > will stop processing whenever it encounters a "0" string element. > for instance "97 32 98 0 99" will result in a 2-element list "a b". > this prevents the user from simply concatenating to strings generated > with [any2string] (since the result of the latter will include a > terminating 0 which will make the former stop when processing the > concatenated list). concatenation ought to work more comfortably, it's true. the lack of nul-handling in [string2any] is easily fixed in principle (strlen() can be replaced by argc), but the guts are just a call to binbuf_text(), which performs the same truncation you describe (probably by calling SETSYMBOL()), and I don't really feel up to writing a whole pd parser from scratch at the moment. > what i would like to have is: > [any2string]: make the string end configurable; > e.g. [any2string 0] will create \0 terminated strings; > [any2string 13 10] will terminate the string with CRLF; > for compatibility reasons i would let [anystring] (without args) output > the 0-terminated list (even though if i had the chance i would prefer to > it to not use any terminating elemets at all per default); one could > imagine a 2nd inlet to set the terminator (sending an empty list would > mean "no termination") makes sense. I put together a first stab a static-buffered [any2string] today, which would mean another optional argument, say: [any2string BUFSIZE TERMINATORS...] ... but the static buffers are still buggy, and it's getting late... > [string2any]: what i would really like, is having [string2any] output > multiple messages if it encounters a "delimiter" (instead of a > "terminator"), e.g. "0"; this would make "97 32 98 0 99" output "a b" > and "c". > [string2any]: analogous to the [any2string] request i would love to be > able to change the delimiter (again: via arguments and/or 2nd inlet); not likely to happen without re-inventing binbuf_text(), which is bit of a monster. ... all of this might be easier to implement if we could ensure that nothing "creative" was going to be passed through any2string/string2any (dollars, escapes, etc.), but that's not really "any" anymore... > 109 097 114 109 111 115 101 116 115 ... with prehensile tails, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdstring feature requests...
moin, On 2007-07-26 10:06:11, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to have written: > Bryan Jurish wrote: >> at some point, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to >> have written: > so i would be quite content if [any2string] would add nothing by itself > and leave the user to manually append a terminating sequence. now implemented and checked into cvs as pdstring-v0.05. the magic incantation is: [any2string BUFSIZE -1], where "BUFSIZE" is the initial (object-local) buffer size, it can be 0 or less to use the default (which I've increased from 32 to 256). >> and I don't really feel up to writing a whole pd parser >> from scratch at the moment. > > well, there is no need to do so. sorry, it was way too late last night -- there is now rudimentary message-separation in [string2any]: it will separate messages on a single end-of-string (EOS) character, specified just like for [any2string]: [string2any BUFSIZE 0] will separate messages on NUL-bytes. Inlets and outlets have been added to protect the innocent, and the defaults are backwards-compatibile. > however, i will just write an object that searches lists for given > sublists and splits them accordingly. that's probably best -- I don't really want to add multiple-character EOS parsing to the [pdstring] stuff, but the single-character version struck me as a pretty sensible way to deal with NUL bytes at least. > i only need a name how about [list_tokenize] ? > so BUSIZE would be the initialy buffersize (which would be adjusted as > longer messages come along)? that's how it is now -- the static version (not built by default, in pdstring/src/any2string_static.c) allocates a single object-local buffer of user-specified size on object instantiation and never dynamically allocates memory in its message-handling routines (it will spit out an error if the buffer overflows). >>> 109 097 114 109 111 115 101 116 115 >> ... with prehensile tails, > > i thought it was goeldi's? ... also. and big hair. Callithrix jacchus, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] KNIF.HAND.CHOP.BOT
i dunno... *** glibc detected: double-free or mutilation at 0x68616e64 *** On 2007-08-06 15:27:05, Hans-Christoph Steiner <[EMAIL PROTECTED]> appears to have written: > Would you trust your life to Pd? How about just your fingers? ;) > > http://www.youtube.com/watch?v=t4uMZOcsxxs > > (A friend just sent me this, I don't know if it's been on this list > before.) > > .hc -- ******* Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:[EMAIL PROTECTED] *** ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] midi controller advice?
moin Conor, On 2007-08-06 23:56:30, Conor J Curran <[EMAIL PROTECTED]> appears to have written: > Hi all, > I was looking around recently for a foot controlled midi controller. The > more expression pedals the better. I was under the impression that the > expression pedals have a range of 0-127 (is this correct?). Yep, that's what mine do. > I was hoping > to map as many expression pedals to a controller number each in order > for each pedal to control some aspect of an external. > > The only midi controller I could find which had a decent number of > pedals was the fatar mp117. ... looks cool, but also very much like an organ-emulator rather than an expression pedal bank. I recently got a behringer fcb1010, which has 2 expression pedals, 10 bang stompers, and 2 vestigial stompers (device-internal use only). I've been using the bangs (via [pgmin]->[route]) to select where the expression pedal data goes (via [sprinkler]), which works quite well. the device itself is cheap but poorly constructed: in particular, the expression pedals use a good 80% of their physical range for maybe 10% of the data range ... with only whole byte values, that's a serious pain ... but hey, it's behringer: what did i expect?. I think roland and yamaha also make 1-2 expression pedal multi-bang stompboxes along the same lines, but have never used them. If I had the time, I'd get an arduino and a mess of burned out wah pedals on ebay and solder my own ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] midi controller advice?
moin Martin, On 2007-08-10 11:54:55, "Martin Dupras" <[EMAIL PROTECTED]> appears to have written: > I also use an FCB1010 with pretty good results. > > I'm not sure I understand that 80% of the range giving 10% of the values > comment. I get almost the full 0-127 range out of the pedals, but the problem is that When a pedal is ca. 80% pressed towards the top of its range, the MIDI value output is only about 13 (~= 127 * 0.1). The remaining 114 values all seem to reside in the final 20% of the physical pedal range. It's a bit of a pain to work with since the "useful" values in the 13-127 range are clumped so closely together, and that makes the pedal seem overly sensitive to me. I've read in another forum that such behavior is common among new-ish fcb1010 versions, and is a consequence of the the mechanical translation from the pedal position to the underlying potentiometer: since a rotary poti is used, the actual value plot ought to follow a sinus curve, but I haven't tested this systematically. > I have an FCB1010 abstraction that I've made. If it's useful to anyone, > email me and I can send it to you. I'm interested! In fact, I've written such an abstraction as well, which I'm also happy to share. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re-targeting sends.
moin Robert, if you're using an older pd, or don't want to update yet, the [sprinkler] external (in CVS and/or pd-extended) acts like a dynamic [send], using its selector (or the first element of its argument list, if the selector is "list", "symbol", or "float") as the name of the send target... marmosets, Bryan On 2007-08-19 04:22:18, Robert Scott <[EMAIL PROTECTED]> appears to have written: > I'd like to be able to send arbitrary length lists down this send, and the > positional parameters wouldn't seem to be able to do this. -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about pd
oops... guess i'm buying ;-) peace, love, & marmosets, Bryan On 2007-10-11 03:48:09, Roman Haefeli <[EMAIL PROTECTED]> appears to have written: > that the next one, who continues this certain thread, pays for > a round of beer. -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: about sexism
On 2007-10-10 16:53:33, "Martin Peach" <[EMAIL PROTECTED]> appears to have written: > 'Barbarian' > is another word that didn't mean anything bad at first...and 'windows' ;) afaik, "barbarian" is derived from ancient Greek for "foreigner", a 'foreigner' being defined basically as 'someone who doesn't speek Greek', hence the term "barbarian", since all these folks could say (according to the originatal users of the word 'barbarian') was "ba ba ba ba ba"... i dunno about you folks, but i think that's a pretty heavy etymological load to carry; certainly heavier than "horde"... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Weighted Randomness
moin moin, I think my [weightmap] external does pretty much what you're describing. It ought to be in cvs under externals/moocow/weightmap. Also, Yves' [probalizer] does basically the same thing, and also includes a GUI and a "training mode" for the weights. marmosets, Bryan On 2007-10-12 19:51:34, "B. Bogart" <[EMAIL PROTECTED]> appears to have written: > Hey all, > > Does someone have a very simple implementation of a weighted randomness > patch where the distribution of the numbers is read from a table? I see > Miller's moses example, but I would like more graphic control of density. -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd to webpage
morning all, On 2007-10-18 19:21:18, "Thomas O Fredericks" <[EMAIL PROTECTED]> appears to have written: > The main difference is that moocow's conversion of a message into a string > appends a 0 at the end of the created list. ... and even that is optional in the newest (cvs) version of [any2string], e.g. by instantiating as [any2string 0 -1]. > On 10/18/07, Thomas O Fredericks <[EMAIL PROTECTED]> wrote: >> The help is in moocow/pdstring-help.pd in the most recent cvs version, there also ought to be moocow/any2string-help.pd and moocow/string2any-help.pd. >> On 10/18/07, Martin Peach <[EMAIL PROTECTED] > wrote: >>> Thomas O Fredericks wrote: >>>> >>>> I believe this approach is more limited that using any2string because >>> all >>>> basic string functions can be recreated once a symbol is converted to a >>>> series of bytes. this was indeed the original motivation of [pdstring], which is, was, and likely ever will be just an ugly hack. My personal opinion is that Martin's solution is much more elegant, and more promising in the long run. Hopefully, at some point I'll be able to implement [any2string] and [string2any] as simple wrappers around [str], but I haven't gotten around to trying it yet ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd to webpage
moin moin, eek, that's an ugly bug you've found there... I'll try and fix it this weekend, in between diaper changes ;-) marmosets, Bryan On 2007-10-18 21:50:41, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to have written: > Bryan Jurish wrote: >> run. Hopefully, at some point I'll be able to implement [any2string] >> and [string2any] as simple wrappers around [str], but I haven't gotten >> around to trying it yet ;-) > > in the meantime, could you have a look at my last bugreport on pdstrings? > > fmg.asdr > IOhannes -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Voice Synth Windows and/or OSX
morning Mark, the "official" distributions of both ratts and pd-flite are available here: http://www.ling.uni-potsdam.de/~moocow/projects/pd additionally, the most current version of pd-flite should always be available in sourceforge cvs: http://sourceforge.net/projects/pure-data in the subdirectory externals/moocow/flite. pd-flite was even buildable by the pd-extended build system last time I looked, but it requires that the flite headers and library are installed on the build machine, which wasn't the case with the default auto-builds (again, last time I checked). ratts has been successfully compiled on osx (i think there's even an older binary version on my website), and assuming that flite itself compiles there, i don't foresee any difficulties for pd-flite, but let me know if you encounter any! i have never tried to compile on windoof myself, but i don't think there should be *too* many problems there either... marmosets, Bryan On 2007-11-09 02:43:05, mark edward grimm <[EMAIL PROTECTED]> appears to have written: > I was looking at the 'ratts' externals and 'pd-flite > v0.01' - just wondering if anyone has successfully > compiled for windows and/or osx. OR any other speech > synthesis/singing synth options for either of these > platforms? > > Thanks! > mark -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Voice Synth Windows and/or OSX
morning Mark, On 2007-11-09 14:45:31, mark edward grimm <[EMAIL PROTECTED]> appears to have written: > maybe ill give a go at compiling the ratts library on > wincrap. ive never compiled anything on win before, > only linux so it will be a learning experience... i > guess :) you have my deepest heartfelt sympathies... is there some particular reason you can't use linux for this project? > i didnt see an osx binary version on your site. only a > binary for "sprinkler v0.06" although it does say in > your ratts readme that there may be one out there > compiled by the same person...Adam T. Lindsay. I > wonder if anyone knows of this library as a binary > somewhere? oops... guess the sprinkler binary is what I was thinking of; haven't seen Adam on the list recently, so i don't know if he's still doing pd-related things or not, and i don't seem to have a copy of it here; sorry. > ratts does NOT need the flite libraries to compile > correct? it doesnt seem like it does by the > documentation... correct: ratts ought to compile "on its own" without any non-standard c libraries. flite sounds much more intelligible though ;-) marmosets, Bryan > --- Bryan Jurish <[EMAIL PROTECTED]> wrote: > >> morning Mark, >> >> the "official" distributions of both ratts and >> pd-flite are available here: >> >> http://www.ling.uni-potsdam.de/~moocow/projects/pd >> >> additionally, the most current version of pd-flite >> should always be >> available in sourceforge cvs: >> >> http://sourceforge.net/projects/pure-data >> >> in the subdirectory externals/moocow/flite. >> pd-flite was even buildable >> by the pd-extended build system last time I looked, >> but it requires that >> the flite headers and library are installed on the >> build machine, which >> wasn't the case with the default auto-builds (again, >> last time I checked). >> >> ratts has been successfully compiled on osx (i think >> there's even an >> older binary version on my website), and assuming >> that flite itself >> compiles there, i don't foresee any difficulties for >> pd-flite, but let >> me know if you encounter any! i have never tried to >> compile on windoof >> myself, but i don't think there should be *too* many >> problems there >> either... >> >> marmosets, >> Bryan >> >> On 2007-11-09 02:43:05, mark edward grimm >> <[EMAIL PROTECTED]> appears >> to have written: >>> I was looking at the 'ratts' externals and >> 'pd-flite >>> v0.01' - just wondering if anyone has successfully >>> compiled for windows and/or osx. OR any other >> speech >>> synthesis/singing synth options for either of >> these >>> platforms? >>> >>> Thanks! >>> mark -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] code and compilers
morning all, On 2007-12-08 21:08:29, Mathieu Bouchard <[EMAIL PROTECTED]> appears to have written: > On Sat, 8 Dec 2007, Andrew Brouse wrote: > >> An old-school hacker (poet turned progammer, classic!) once told me >> that he used to debug his programmes (on mainframes, with not even 1M >> of memory) by actually just watching a display of activity in all >> memory locations. After a while, he just subconsciously internalised >> what was going on and managed to debug the code. > > This can't possibly be used nowadays, but there are better ways of > visualising code. Because C values are typed, you can (to a certain > extent), view the data topologically, by following pointers, which get > drawn like arrows that are connecting boxes containing data. This is > what DDD does (it's a GDB wrapper). This is more useful because the > positions in memory are somewhat meaningless, because the connectedness > of the data happens because the program follows pointers rather than > using any arithmetic other than for a single array or struct. In fact, i recently spent about 2 days chasing a bug in some old code of mine that i only managed to track down by looking at the literal memory positions, and if I had had a spiffy blinky pseudo-analogue StarTrek kind of data display, I probably would have seen the bug immediately, whereas it took me the said 2 days using ddd.... oh well ;-) marmosets, Bryan (philosopher-turned-hacker) -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] string padding
moin Andy, This is quite easy using [string2any] and [any2string] together with pd's [list] operations. see attached example patch. I'm sure the same basic idea can be used to pad [str] strings as well... marmosets, Bryan On 2007-12-16 20:54:20, "Andy Graybeal" <[EMAIL PROTECTED]> appears to have written: > greetings > > i'd like to pad a string... say for instance i want to pad the string > "andy" and "ian" to be able to have a total of 10 characters, and the > padding character will be an underscore. so the end result would add 6 > underscores to the string "andy" and seven underscores to the string > "ian": > "andy__" > "ian___" > > i poked around through extended and did a search on the list archives for > "character pad" and "string pad", nothing came up in the archives, and the > only things i found in extended are mrpeach's [str] help examples, and > moocow's [string2any], [any2string] help examples. it looks like > mrpeach's stuff is the closest to what i want, but i don't think it's what > i want. after tofofmtl introduced me to pdmtl, i expected there would be > some string handling in to coincide with the list stuff they have too, but > nothing there. > > thanks, > andy -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology #N canvas 688 480 470 300 10; #X msg 206 101 _; #X msg 236 101 .; #X msg 23 99 foo; #X msg 55 99 bonk; #X msg 266 101 x; #X floatatom 350 104 5 0 0 0 - - -; #N canvas 344 148 570 314 pad_string 0; #X obj 48 16 inlet; #X obj 48 76 any2string 0 -1; #X obj 48 131 list split 10; #X obj 48 221 outlet; #X obj 48 155 string2any 0 -1; #X obj 210 12 inlet; #X obj 48 105 list append 95; #X text 59 37 string; #X text 219 33 default; #X obj 210 75 t l l; #X obj 240 101 list length; #X text 123 191 Since we have a default string-list of the desired length in the right inlet \, all we have to do is append it to the stringified message on the left inlet and discard anything beyond the padding limit. On the way out \, we convert the string-list back to pd-messagehood with string2any.; #X connect 0 0 1 0; #X connect 1 0 6 0; #X connect 2 0 4 0; #X connect 4 0 3 0; #X connect 5 0 9 0; #X connect 6 0 2 0; #X connect 9 0 6 1; #X connect 9 1 10 0; #X connect 10 0 2 1; #X restore 100 182 pd pad_string; #N canvas 76 80 482 372 default_string 0; #X obj 40 18 inlet; #X obj 222 18 inlet; #X obj 222 264 outlet; #X msg 222 239 95 95 95 95 95 95 95 95 95 95; #X obj 222 149 until; #X msg 329 217 set; #X obj 222 126 t f b; #X obj 40 82 t b f; #X msg 222 217 add2 \$1 \, bang; #X obj 222 106 f 10; #X obj 222 194 f 95; #X obj 40 60 any2string 0 -1; #X text 83 19 pad_char; #X text 265 19 default_length; #X text 31 295 Here \, we use "add2" and "set" messages to a msgbox to build a default string of the desired length. This could be done more efficiently \, but it ought to suffice to illustrate the principle. ; #X connect 0 0 11 0; #X connect 1 0 9 0; #X connect 3 0 2 0; #X connect 4 0 10 0; #X connect 5 0 3 0; #X connect 6 0 4 0; #X connect 6 1 5 0; #X connect 7 0 9 0; #X connect 7 1 10 1; #X connect 8 0 3 0; #X connect 9 0 6 0; #X connect 10 0 8 0; #X connect 11 0 7 0; #X restore 236 138 pd default_string; #X text 215 83 padding char; #X text 355 87 pad to length; #X msg 93 99 grok it; #X obj 206 18 loadbang; #X obj 100 207 print padded; #X msg 297 101 ?; #X text 25 81 raw message to pad; #X msg 350 55 10; #X connect 0 0 7 0; #X connect 1 0 7 0; #X connect 2 0 6 0; #X connect 3 0 6 0; #X connect 4 0 7 0; #X connect 5 0 7 1; #X connect 6 0 12 0; #X connect 7 0 6 1; #X connect 10 0 6 0; #X connect 11 0 0 0; #X connect 11 0 15 0; #X connect 13 0 7 0; #X connect 15 0 5 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach tcpclient float to string decoder, mayby str ?
moin moin, On 2008-01-06 22:02:47, Damien Henry - Voxler <[EMAIL PROTECTED]> appears to have written: > Of course tcpclient returns lists of floats as it is designed for this, > but i need to convert thoses lists of floats to list of symbols. If you're using vanilla pd, you could also use [any2string], included in the [pdstring] library, which is available here: http://www.ling.uni-potsdam.de/~moocow/projects/pd/pdstring-0.03.tar.gz or in sourceforge cvs. If you're willing to patch your pd sources, I think Martin's [str] objects are a better solution, though. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Split symbol into individual characters
moin Jerome, you could use [any2string] to map a symbol to a list of float values, and then use [string2any] to map those values back onto single-character atoms... I believe the [pdstring] objects are in pd-extended; otherwise they're available in sourceforge cvs or from me: http://www.ling.uni-potsdam.de/~moocow/projects/pd ... Martin Peach's [str] utilities can do all of this a wee bit more elegantly, but require that you patch your pd sources. marmosets, Bryan On 2008-01-16 14:12:22, Jerome Tuncer <[EMAIL PROTECTED]> appears to have written: > Hi list, > > I'm looking for a solution to split a symbol into its own individual > characters. Something a bit like Max's [spell] object... > > Anyone came up with this situation before ? -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Split symbol into individual characters
oops, forgot about that one ;-) tmtowtdi, Bryan On 2008-01-16 14:23:44, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to have written: > Jerome Tuncer wrote: >> Hi list, >> >> I'm looking for a solution to split a symbol into its own individual >> characters. Something a bit like Max's [spell] object... > > [symbol2list] with an empty symbol as delimiter (the default is the > space-symbol) -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] New machine - sound hardware?
morning Ed, morning all, On 2008-02-04 21:54:51, Ed Kelly <[EMAIL PROTECTED]> appears to have written: > 2. What MIDI interface under Ubuntu? I have tried and tried again to > get a Midisport 2x2 working with both the source code (both versions > - 0.5 and 1.2) and the Ubuntu packages - no luck! > > 3. USB audio interface? I know this is a long shot...ALSA has never > worked with PD on any computer I have owned. > > Searching the archives lead me to few emails, one success with > freeBoB and an Edirol interface was the only optimism I found. At the risk of re-iterating said optimism, I can only say that I am in fact (still) quite happy with my Edirol UA-25 (USB): 2in (symmetric) / 2out (asymmetric) + MIDI, running debian unstable with a patched 2.6 kernel on an IBM/Lenovo T42 (which I bought about a year ago after my laptop was stolen: you have my deepest most heartfelt sympathies). Good luck! marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] soundfiler alternative - realtime? (loading in background)
moin Ingo, moin all, I've used a similar trick with [readanysf~] (no upsampling, just a "background" [tabwrite~]). It's even possible to simulate "-resize" e.g. with [wavinfo], but re-allocating tables is generally a Bad Idea if you want to avoid dropouts. marmosets, Bryan On 2008-02-12 13:14:14, Claude Heiland-Allen <[EMAIL PROTECTED]> appears to have written: > Ingo Scherzinger wrote: >> Hi, >> >> does anybody know if there is an alternative method to soundfiler in >> order to load wave files into tables. > > [readsf~] and [tabwrite~] in an upsampled subpatch (with [block~]). > > No -resize support there though, and it's only "N times" faster than > real time, not "as fast as possible without dropouts". > > > Claude -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT]TTS
moin Reinhard, I don't really know of any open source German TTS systen (although way back when, someone appears to have hacked some German Holmes-elements into rsynth -- not sure of the status of that code; best to ask rsynth's maintainer (Nick Ing-Simmons) if you want to go that route, which I suspect you probably don't), so... "free-as-in-free-beer" systems, yes: check out HADIFIX and the 'txt2pho' program from (I believe) the Universität Bonn, for use with MBROLA (free for non-commercial and non-military use). There's also an add-on module for the free, open-source festival TTS system. The German add-on itself is available under an MBROLA-like license from the IMS Stuttgart. Warning here: I've never actually gotten the whole ims-german-festival package to compile under current versions of festival: I think the project ran out of money and no one's been maintaining that code for several years now -- you may have better luck with an older version of festival itself and/or more scheme hacking than I was prepared to do ;-) You might also checkout BOSS (also from Uni Bonn), which I've never looked at, but is the successor system to HADIFIX. BOSS itself is supposed to be open source, but the voices and language models are (unfortunately) still proprietary, AFAIK. Please let me know if you manage to dig up anything better! marmosets, Bryan Some URLs: rsynth: ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/synthesis/rsynth-2.0.tar.gz festival: http://www.cstr.ed.ac.uk/projects/festival HADIFIX/txt2pho: http://www.ikp.uni-bonn.de/dt/forsch/phonetik/hadifix/HADIFIXforMBROLA.html BOSS: http://www.ikp.uni-bonn.de/dt/forsch/phonetik/boss/index.html MBROLA: http://tcts.fpms.ac.be/synthesis/mbrola.html Comparison of TTS Systems for German: http://www.8hertz.com/tts/tts.html On 2008-03-06 20:40:00, Reinhard Handl <[EMAIL PROTECTED]> appears to have written: > hello list, > > sorry for the off-topic, but i dont know where to ask: > > does anybody know a free or opensource TTS with a german male voice? > > any hints appreciated, > > thx, reinhard -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vowel recognition
moin Marius, moin list, sorry, haven't tried it yet -- i'm more interested in getting funny noises out of pd than into it ;-) Maybe Andy Farnell has done something along these lines? Speculating wildly (e.g. without any experience in vowel detection), I think [fiddle~] probably won't work on its own: it's designed to detect the fundamental frequency (f0), whereas vowels will differ primarily in the formants: maybe an fft approach would work? or perhaps you could have several instances of [fiddle~], tweaking the parameters such that each detects a single formant? ... just wild speculation ... marmosets, Bryan On 2008-03-11 00:35:42, marius schebella <[EMAIL PROTECTED]> appears to have written: > hi, > I wonder if anyone did vowel recognition with Pd. Maybe ed kelly? or > brian j.? > can it be based on fiddle~ or does it neeed more/other objects/technology? > marius. -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] VOSIM - Voice Synth and similar
moin Luigi, well, you can get the [klatt~] speech synth that comes with [ratts] to "sing" with a bit of elbow work (and at least one frame of oracular foresight)... [ratts] is currently just available from me: http://www.ling.uni-potsdam.de/~moocow/projects/pd ... later versions may be bundled into pd-extended, but that's currently not possible. marmosets, Bryan On 2008-04-06 12:42:24, Luigi Rensinghoff <[EMAIL PROTECTED]> appears to have written: > Hi List... > > I came across that email, when i searched the archive list for > voice-synths for PD. > > For a Project i would like to have a synthesized "singing" voice. > > Any Suggestions, which Patch, External or other implementation to look > for ?? > > Actually Perry Cooks "Spasm" seems to be the most "complete" - correct > me if i am wrong... > > Somewhere i read that there was a PD-Patch planned, but i guess it was > never made public. > > > > Concerning [paf~], the readme tells that it is a Percussion Detector ?? > > Thanks, Luigi > >>vosim, chant, spasm, and Perry Cooks new thing >>that follows lip positions, and in Pd there >>if [paf~], and if you can't find it for any reason >>I have the source. > >>andy > >>On Sat, 26 May 2007 19:36:07 + >>"josue moreno" wrote: > >> Hi everyone, >> >> can anyone tell me if there is some software for simulate singing > voices? It >> can be cool if there is a spanish oriented one >> >> my OS is Mac OS X 10.4.8 ppc >> >> thanks -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] get sample length for setting array size
moin robert, [readsf~] and [readanysf~] will both read directly from the filesystem. [readanysf~] is more flexible, but was acting a bit flaky last time I had to compile it (sorry, can't be more specific at the moment; too many ecstatic football fans in my neighborhood) ;-) marmosets, Bryan On 2008-06-19 23:03:24, smilingmolecule <[EMAIL PROTECTED]> appears to have written: > Claude Heiland-Allen wrote: >> [openpanel] >> | >> "read -resize $1 my-table" >> | >> [soundfiler] >> | >> new length of table >> >> >> Hope this helps, >> >> >> Claude > hey claude, > you helped me a lot. > the only thing i realize now, is that pd slows down when the sample size > is to great. > is there an alternative to play long samples? > > thanks a lot. > /robert -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] tape-like transport emulation (search for external)
moin ilya, for the "pure" diy approach, [soundfiler], [table], and [tabread~], [tabread4~] and/or one of the new interpolation variants ([tabread4c~]?) that have been floating around the list recently are the way to go. you might also want to have a look at Thomas Grill's xsample~ library (esp. [xgroove~])... marmosets, Bryan On 2008-06-19 23:31:43, [EMAIL PROTECTED] appears to have written: > hello list! > > i got back to pd after a little break ;) > > i had made a few recording which i had been trying to master in Snd, > but Snd has weired set of options which i like ..but sometimes it's > really unstreightforward ;( > > so .. basically i just came with an idea of a mastering suit, i mean a > set of abstraction which would have quite similar approach as you do > have in recording studio! > first thing i need right now is a mixdown patch, which is nearly ready; > i wnna mix 4chan -> stereo. the panning and amplification are implemented > (well, in a weired way, but i like it that way). > the concept is to do all in pd, cause i couldn't get jackd running and > just don't want it really. > i'm sure pd is capable for doing most of what i need and this is a > proof-of-concept project actually ;) > > so i wish to do some editing in Snd and the do live-mode mixdown iside pd. > > i have got it working quite ok with [readsf~], but it takes only play and > stop control commands ;[ > > *IDEALY*, i'd wish to have tape-like transport with timecode and all > other imaginable features, .. > but actually the timecode and marking ..etc could be implemented > externaly with basic objects ;) > i really need some external which could rewind and fastforward with the > sound like tape makes ..surely that will be fun for others as well! > > i couldn't find anything really .. > > can quite imagine the way of doing it with [soundfiler] and a set of > tables ..but i reckon that isn't quite right in case of 4 or 6 channel > files up to 10min (oor even longer). > again, surely many people are gonna suggest to use jackd and jamin, > but as i have just said - i'm traying to implement a pure data > mastering suit ;] > > does anybody know an external which would do that kind of thing? > > > > cheers, -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Ratts object on OSX
moin DH, never tried it on OSX myself, but [ratts~] is just an abstraction. try looking at the help files for e.g. [klatt~], [holmes], and the like to figure out at least which object is complaining at you... it may be that something in ratts is indeed broken (your error message looks hauntingly familiar, but I can't remember in what context I last saw it...), but I suspect there may be an easier fix... marmosets, Bryan On 2008-06-28 00:20:26, dh254 <[EMAIL PROTECTED]> appears to have written: > Compiled and running on osx 10.5.3 (flite as well) but getting errors: > > Can anyone help -- has anyone successfully used this object on leopard? > > error: inlet: expected '' but got 'bang' > error: inlet: expected '' but got 'bang' > error: inlet: expected '' but got 'bang' > ... > > Thanks much, > -DH -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Ratts object on OSX
moin dh, yep, all of these objects are defined by the ratts library. Just to get the obligatory question out of the way, are you starting pd with "-path /my/externs/dir -lib ratts"? and does /my/externs/dir contain "ratts.pd_WHATEVER" ? (assumedly "ratts.pd_darwin" for osx) ? If so, do you see a message like: ratts: Realtime Analog Text-To-Speech externals v0.07 by Bryan Jurish ratts: Based on text-to-speech code by Nick Ing-Simmons and Jon Iles ratts: and PD external code by Orm Finnendahl and Travis Newhouse ratts: compiled by USER on DATE on the pd console at startup? marmosets, Bryan On 2008-06-28 01:39:11, dh254 <[EMAIL PROTECTED]> appears to have written: > hmmm, when i add just the one ratts~ object to a new patch, I get the > console output below, so it seems like maybe none of the objects are > being created? > > ratts > ... couldn't create > klatt~ mspf 5 > ... couldn't create > rattshread $1-dict > ... couldn't create > number2text > ... couldn't create > guessphones > ... couldn't create > phones2holmes > ... couldn't create > rattstok > ... couldn't create > toupper > ... couldn't create > spellout > ... couldn't create > holmes > ... couldn't create > > when I do a find last error, I get: "no findable error yet" > -DH -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use [tcpserver] in a non-OSC context?
moin Martin, moin Roman, On 2008-08-13 19:25:20, Martin Peach <[EMAIL PROTECTED]> appears to have written: > Roman Haefeli wrote: >> On Tue, 2008-08-12 at 18:45 -0400, Martin Peach wrote: >>> Roman Haefeli wrote: >>>> hi all >>>> >>>> i would like to rewrite the netpd-server patch using [tcpserver], but i >>>> cannot figure out how to convert 'list of number' messages into ascii >>>> messages. >>>> > > Yes, maybe a [serialize] and [unserialize] would be a good idea. > [unserialize] would take a list of integer floats, interpret them as > ascii, and convert it to a single symbol, and [serialize] would take a > symbol and convert it to a list of integer floats on [0..255]. > Converting floats and lists raises problems though (should a float be > converted to its ascii or binary representation? How to tell if a list > of floats is meant to be decoded as symbols or floats?). > > I think [moocow/any2string] and [moocow/string2any] already do this, yep, that's pretty much exactly what they do, except [string2any] outputs a list, rather than a single symbol (...but you can always patch it into [list2symbol] from zexy if you need a single symbol). for non-symbol arguments, [any2string] does whatever t_binbuf does (probably truncating floats, performing dollar-substitutions, etc...). > but > I can't tell right now because they don't seem to be in my Pd > 0.40.3-extended-20080719, or I'm not looking in the right place. looking at the debian-stable and debian-testing debs from 2008-07-19, they ought to live in /usr/lib/pd/extra/moocow/any2string.pd_linux rsp. /usr/lib/pd/extra/moocow/any2string.pd_linux. the only pd-extended system on which my externals still don't build in windoof/mingw32, because that box is still using a broken version of make. what system are you using, Martin? There are also (probably old and stale, possibly broken) copies in /usr/lib/pd/extra/flatspace, which should probably just get deleted (along with sprinkler). I assume these come from externals/build/src; I'll just go ahead and remove them and see if anyone hollers... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use [tcpserver] in a non-OSC context?
moin Martin, On 2008-08-14 00:51:53, Martin Peach <[EMAIL PROTECTED]> appears to have written: > Bryan Jurish wrote: >>> but >>> I can't tell right now because they don't seem to be in my Pd >>> 0.40.3-extended-20080719, or I'm not looking in the right place. >> looking at the debian-stable and debian-testing debs from 2008-07-19, >> they ought to live in /usr/lib/pd/extra/moocow/any2string.pd_linux rsp. >> /usr/lib/pd/extra/moocow/any2string.pd_linux. the only pd-extended >> system on which my externals still don't build in windoof/mingw32, >> because that box is still using a broken version of make. what system >> are you using, Martin? > > Yes I was using WinXP. I also have an Ubuntu machine which does have the > moocow objects. > I wonder what it is about those objects that makes them difficult to > compile on Windows...I just looked through any2string.c and it looks > like an ordinary source file for a pd external, except for the debug > macro A2SDEBUG and the PACKAGE_VERSION, which should probably be defined > in a header file, not the makefile. afaik, there's no reason the objects shouldn't compile; the problem is that my pd-extended build rules use GNU make macros, and the make on the PdLab winxp build machine is "broken" (v3.79), meaning it doesn't handle macros propertly. i'm also unsure whether "configure" & co will work on mingw32, but that I can test (later... currently on baby duty)... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] error compiling any2string
morning all, On 2006-12-13 09:34:25, IOhannes m zmoelnig <[EMAIL PROTECTED]> appears to have written: > > Miguel Cardoso wrote: >> >> I get this error compiling any2string.c >> >> does anyone have these moocow externals compiled for mac intel? >> > did you use "./autogen.sh && ./configure && make" or just "make"? > you are trying to compile an application instead of a dylib. There's a default './configure' already packed into the distribution on my website (http://www.ling.uni-potsdam.de/~moocow/projects/pd/pdstring-0.03.tar.gz), so you can build & install without the autotools installed locally (i.e. without running ./autogen.sh) just by running "./configure && make && make install". > thinking of this, i am not sure, whether pdstring's build-system really > supports os-x (i haven't looked, so forgive my ignorance). I'm not sure either ;-) I did copy the "darwin" section from the configure.in of pd (v0.35-test16), and have had success reports for other externals, but lacking an os-x machine, i can't test the support myself. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
morning all, I've been chasing a bug for several weeks now that I just can't seem to get my head around: symptoms are segfaults and complete crashes in pd (v0.40-2 vanilla) on linux/x86 [debian unstable, gcc 4.1.2]. gdb backtraces are available, and I've just recompiled using identical CFLAGS everywhere (-O3 -march=pentium-m -msse -msse2 -mfpmath=sse -ffast-math -funroll-loops), since I had feared that -malign-double might have been biting me, but this doesn't appear to have been the case... Buglet the First (solved, kinda) === - description: [pool] and [readanysf~] don't play nicely together - symptom: the (infamous) libc message on stderr when closing a patch: *** glibc detected *** free(): invalid pointer: 0x0823e46c *** + apparently caused by some goofiness with the flext delete() operator (backtraces etc. available) - solution (I think, thanks to the list archives): + compile both flext and readanysf~ with -DFLEXT_USE_CMEM + readanysf~ really seems to need FLEXT_USE_CMEM flext-globally (I can provide a pretty complete and systematic list of the configurations I've tried: it's possible to compile and run successfully without FLEXT_USE_CMEM, but things break more or less randomly at runtime then: particularly, the "stop" message to readanysf~ segfaults pd) - solution (I think, thanks to the list archives): + this seems to work for [pool] and [readanysf~], but... Buglet the Second (please assist!) === - description: [fluid~] in abstractions crashes pd + having compiled flext with -DFLEXT_USE_CMEM, loading any abstraction containing a [fluid~] object causes pd to segfault (see below) + bug occurs even without any other externals loaded + oddly, I *can* create [fluid~]s by hand, (but not load them in an abstraction, which makes the object pretty useless, im(ns)ho) + any ideas why fluid_init() is trying to initialize this==NULL ? - this appears to be FLEXT_USE_CMEM related, since I didn't get these symptoms without FLEXT_USE_CMEM in flext itself + I can't just -UFLEXT_USE_CMEM for fluid~, because: (a) that would break readanysf~ if I did it flext-globally, and (b) if I undefine FLEXT_USE_CMEM only for fluid~, I get undefined linker symbols at runtime: /usr/local/lib/pd/extra/fluid~.pd_linux: \ /usr/local/lib/pd/extra/fluid~.pd_linux: undefined symbol: \ _ZN19flext_root_single_ddlEPv \ fluid~: can't load library + would it help to fork the flext build procedure (again!), basically adding another library suffix for FLEXT_USE_CMEM, since its effects appear not to be restricted to the headers? - if the suffix were, say, 'c', where we now have: libflext-pd((_d)?.so|_[st]d?.a) we would get: libflext-pd((_c?d?).so|_[st]c?d?.a) - i know this is ugly, and I'm not even sure it would work, but I'm at my wits' end here... I hope somebody can shed some light on this for me... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210693952 (LWP 24068)] 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) backtrace #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/libfluidsynth.so.1 #2 0x08237bd0 in ?? () #3 0x0811ace0 in mstack.5434 () #4 0xbfd76828 in ?? () #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, argv=0xb7caf730) at fluid/main.cpp:251 Previous frame inner to this frame (corrupt stack?) marmosets, Bryan ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] osc
[second attempt at sending, since my new machine is not yet fully configured and the first attempt bounced :-/] moinmoin, yep, that's what OSC is for -- sending to arbitrary IP addresses. be warned though, that since OSC (usually) uses UDP as its transport, your packets might get lost en route; although even the intercontinentally ballistic osc barrages i've sent (1 packet every 50ms or so, from ISP#1(Germany) to ISP#2(USA) using 56k analog modems on both endpoints) by and large seemed to get through intact... marmosets, Bryan On 2007-01-29 02:31:38, [EMAIL PROTECTED] appears to have written: > hi, perhaps the names of these are different than what i'm calling > them but i was under the impression that a computer has two ip > address (at least). one is private or local, the other is used by the > internet like websites. the second can also be found by going to > websites like http://whatsmyip.org/ . I don't have a computer with PD > at the moment, was wondering if oscx could send data to that second > type of ip address. So, if one could send information (or receive > information) using the less private ip address using osc in pd. > > If making this inquiry a touch more clear would be of good cause, I'd > be fast to be of aid. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
(fluid_init() probably calls malloc() [I haven't checked, but it seems likely], and SndObj's Mixer::~Mixer() is definitely calling delete()). This looks to me at the moment as if it might have to do with a conditional I don't fully understand in flsupport.cpp at around line 111, which tests (I think) for "large" allocations in threaded flext externals without FLEXT_USE_CMEM defined. I haven't run the debugger over it yet, so I don't know for certain. Maybe Thomas has some ideas. > So frustrating, I have finished my first PD external (Multi stereo comb > filter) and I want to release it properly but I can't with this bug in > it !!! Keep at it -- it will come together eventually! (but cf. signature ;-) marmosets, Bryan > Conor > > > Thomas Grill wrote: >> Hi Bryan, >> i think it would be a good idea to define FLEXT_USE_CMEM in the flext >> build system by default. >> Currently pd doesn't use anything different than C memory allocation >> (in getbytes, freebytes) so there's no real reason to not to. >> Concerning your fluid problems i can't really help, since i don't use >> it, but i'm sure there are some experts who can. > >> all the best, >> Thomas > > > Am 28.01.2007 um 17:17 schrieb Bryan Jurish: [snip] >> + would it help to fork the flext build procedure (again!), >> basically adding another library suffix for FLEXT_USE_CMEM, >> since its effects appear not to be restricted to the headers? >> - if the suffix were, say, 'c', where we now have: >> libflext-pd((_d)?.so|_[st]d?.a) >> we would get: >> libflext-pd((_c?d?).so|_[st]c?d?.a) >> - i know this is ugly, and I'm not even sure it would work, >> but I'm at my wits' end here... I hope somebody can shed >> some light on this for me... >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread -1210693952 (LWP 24068)] >> 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) backtrace >> #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 >> #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/ >> libfluidsynth.so.1 >> #2 0x08237bd0 in ?? () >> #3 0x0811ace0 in mstack.5434 () >> #4 0xbfd76828 in ?? () >> #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, >> argv=0xb7caf730) >> at fluid/main.cpp:251 >> Previous frame inner to this frame (corrupt stack?) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
moin Conor,
On 2007-02-06 00:50:17, Conor J Curran <[EMAIL PROTECTED]> appears to
have written:
> Hi Bryan
> Thanks for the help on this.
>
> I added this as you specified above but now when I try to load the patch
> which contains the external PD crashes. It is somewhat sporadic. I then
> recompiled a debug version of the external. I narrowed down my problem
> now to when there are more than one flext external open in the patch.
> The patch will not open if this is the case. (Bryan's problem number
> two - I'm playing catch up;-).
sounds familiar indeed... have you by any chance tried compiling your
external without threads, linking (statically) to libflext-pd_s.a ? I
don't know if you need threads or not, but at least that might narrow
down the range of possible error sources...
> BTrace from a crash on start up.
> #0 0x007d0f00 in ?? ()
> #1 0xb7ea32c0 in __free_tcb () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0x0001 in ?? ()
> #3 0xb7dd4186 in calloc () from /lib/tls/i686/cmov/libc.so.6
> Previous frame inner to this frame (corrupt stack?)
>
> Next below is the GDB trace when I attempt to attach GDB to PD after
> previously manually the external symbols by hand to GDB. I don't know if
> this has anything to do with it:
>
> `system-supplied DSO at 0xe000' has disappeared; keeping its
> symbols.
> warning: Cannot initialize thread debugging library: unknown thread_db
> error '22'
> warning: Cannot initialize thread debugging library: unknown thread_db
> error '22'
I've seen something like this too; but am not sure what it means :-/
> Next is the trace (out to terminal)from PD when the external is managed
> to be loaded properly deleted.
>
> invalid command name ".x82578d0.c"
I see these more frequently than I'd like to admit: my guess is that
these are errors from Tk ("invalid command name" is a Tcl/Tk error)
caused by pd-gui objects which have ceased to exist but which for some
reason are still hooked up to at least one Tk callback. Not dangerous
as such, but indicative of something goofy going on somewhere.
> And finally the BT when the patch is attempted to be opened with two
> externals present.
>
> #0 0xe410 in __kernel_vsyscall ()
> #1 0xb7e844c3 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0x08230d18 in ?? ()
> #3 0x080ffebc in oss_send_dacs ()
> #4 0x0810dbd1 in _IO_stdin_used ()I would really like to get on to
> building another external asap.
> #5 0xbffab684 in ?? ()
> #6 0xbffab638 in ?? ()
> #7 0x38fd in ?? ()
> #8 0xbffab54c in ?? ()
> #9 0x0810dbd1 in _IO_stdin_used ()
... I'd try it without FLEXT_THREADS (libpthread), both with and without
FLEXT_USE_CMEM: that might make things clearer. I think this can be
accomplished by:
(a) ensuring that FLEXT_THREADS is undefined for your external
(-UFLEXT_THREADS)
(b) linking to the static single-threaded flext library, libflext-pd_s.a
... hmm, looking at it, it seems that the default shared libflext-pd.so
is threadless, but is nonetheless compiled and linked with the -pthread
option. Maybe it might help to remove the "-pthread" compiler & linker
flags for threadless (shared,single) builds: this amounts to editing
flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the
dark, but at least it would make debugging easier ;-)
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
[EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
fluid~ bug (was: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't))
morning all, I take it all back and assert the opposite! Regarding the following fluid~ error: >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread -1210693952 (LWP 24068)] >>>> 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 >>>> (gdb) backtrace >>>> #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 >>>> #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/ >>>> libfluidsynth.so.1 >>>> #2 0x08237bd0 in ?? () >>>> #3 0x0811ace0 in mstack.5434 () >>>> #4 0xbfd76828 in ?? () >>>> #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, >>>> argv=0xb7caf730) >>>> at fluid/main.cpp:251 >>>> Previous frame inner to this frame (corrupt stack?) This is just a plain old initialization bug in fluid/main.cpp. It seems that fluid::fluid() calls fluid::fluid_init(), which calls libfluidsynth's delee_fluid_synth() if (this->synth != NULL), which is complete and utter hogwash at initialization time unless this->synth has been initialized to NULL, which (apparently) happens just in case we're using flext's new() and delete() (!defined(FLEXT_USE_CMEM)) rather than pd's getbytes() (defined(FLEXT_USE_CMEM)), so: Frank, would you have anything against my chaning line 51 of fluid/main.cpp in CVS from: fluid(int argc, t_atom *argv) to: fluid(int argc, t_atom *argv) : synth(NULL) ? Finding this one at least makes me feel somewhat better, although readanysf~ is still giving me headaches... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
moin Conor, On 2007-02-07 01:12:05, Conor J Curran <[EMAIL PROTECTED]> appears to have written: >> sounds familiar indeed... have you by any chance tried compiling your >> external without threads, linking (statically) to libflext-pd_s.a ? I >> don't know if you need threads or not, but at least that might narrow >> down the range of possible error sources... > I have not but I was under the impression that if I was to compile my > external in the current flext setup using single-release. This would imply no > use of threads and also statically linking to the .a lib as opposed to the > .so. > Is this correct? If not what do I need to do to ensure I do so? Sorry > but I might have mentioned before I pretty clueless with this gcc stuff. yep, afaik any -single build should produce a threadless (the official term in Thomas' documentation appears to be "single-threaded") version; at least, the flext build system won't define FLEXT_THREADS for *-single builds. Just make sure you're not defining it yourself ;-) >> ... I'd try it without FLEXT_THREADS (libpthread), both with and without >> FLEXT_USE_CMEM: that might make things clearer. I think this can be >> accomplished by: >> >> (a) ensuring that FLEXT_THREADS is undefined for your external >> (-UFLEXT_THREADS) > Should -UFLEXT_THREADS be added to my config.txt in the external > directory. > > UFLAGS += -UFLEXT_THREADS ? > Or should I ensure it is no defined. -U = undefine ? If you're not defining it (e.g. with -DFLEXT_THREADS or with a #define in some source file), then you're ok: it won't be defined by flext build.sh for a *-single build. >> Maybe it might help to remove the "-pthread" compiler & linker >> flags for threadless (shared,single) builds: this amounts to editing >> flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the >> dark, but at least it would make debugging easier ;-) > I have edited this file so now the part which did contain the pthread > stuff looks like this > ## > #removed from both: -pthread > CFLAGS += -fPIC > LDFLAGS += -shared yep, that's the bit I meant. As I noted yesterday, my fluid~ problems were due to a missing initialization / assumed zero-initialization of the object's memory, which resulted in an attempt to free() a pointer of basically random junk (either unallocated or allocated by a different program or thread or whatever)... According to the gcc docs: -pthread Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags. ... there are -pthread flags listed for other architectures too, and gcc doesn't complain about the flags, but I haven't yet found any docs for the -pthread option on x86, so maybe it doesn't do anything at all here except maybe link to libpthread... > One question are you working from 5.0 release of flext or are you using > the head of cvs? I'm using the head of cvs, and I haven't actually removed the "-pthread" from my build flags here. Of course, I am still getting bizarre crashes & lockups, but not the fluid~-related ones. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] re-animate PD - Stammtisch Berlin ??
moin Sukandar, moin Luigi, moin all, I might crawl up out of my cave for another Pd-Berlin Stammtisch as well... marmosets, Bryan On 2007-04-11 14:41:17, Sukandar Kartadinata <[EMAIL PROTECTED]> appears to have written: > On 11.04.2007, at 11:24, Derek Holzer wrote: > >> me if it's in May. > > similar here - sensor workshop until end of April... > > we do a presentation at the end of it, April 28th, 20:30, if anyone's > interested > (hmm, maybe we could even turn that into a Stammtisch, whaddya think?) [snip] >>>>> Am 06.04.2007 um 16:30 schrieb Luigi Rensinghoff: >>>>> >>>>>> I was wondering if anyone based in Berlin is interested in re- >>>>>> animate >>>>>> some kind of unofficial PD-Stammtisch/Meeting. >>>>>> >>>>>> Let me know ;-) Let us meet ;-) >>>>>> >>>>>> >>>>>> Luigi -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] USB Sound "card"
moin David, I just recently acquired an Edirol UA-25 with which I'm quite happy (2 channel analog|digital audio I/O, MIDI). I've also heard good reports of the Terratec Phase 26 (are you out there Frank?), but have no experience with it myself. In general, I'd advise you to avoid M-Audio's USB audio devices under linux: I think the best that can be said for these is that "some of them work some of the time": my M-Audio Quattro is currently gathering dust in the closet ;-) If you can afford it, I think that the RME "Hammerfall" series is the Way To Go (note capitals)... marmosets, Bryan On 2007-05-04 15:53:27, "David F. Place" <[EMAIL PROTECTED]> appears to have written: > Hi, everyone. > > I hesitated to post this question, because it seems like such an > obvious FAQ. I couldn't find the answer by searching around. > > My linux workstation has a crappy, noisy sound card. I want to > replace it with a higher quality device. Preferably outside the box > to avoid interference. I notice that several manufacturers offer > solutions, Creative, M-Audio, etc. Is any preferred by Pders? > Please discuss. > > I have a digidesign M-Box that I use with pro-tools on my mac. Of > course, it won't work with linux or, for that matter, with most > versions of Pd on OSX. I mention it to give an idea of the quality > level that I desire. > > Cheers, David > >___ > (---o---o-o-o---o-o-o( > David F. Place > mailto:[EMAIL PROTECTED] > > > > _______ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] USB Sound "card"
moin David, moin list, Nope, I had no problems at all with the UA-25: in "basic mode" (44k, 16bit, no MIDI), it works "out of the box". In "Advance mode" (44|48k duplex, 96k simplex, or anything involving MIDI) I've been using the ALSA plugin layer (probably related to the fact that in this mode the device uses 24 bit samples), and have had problems with OSS emulation (these might have been just MIDI-related; I can check if it's critical to you), but running pd with '-rt -alsa' or using jack works like a charm. Sound quality is quite good: the ua-25 makes the onboard chip (intel i8x0) on my laptop sound like an RCA-Victor from ca. 1927; subjectively, I'd say it's comparable to the ICE1712 pci card in my desktop. Also, I personally love having the mixer elements in hardware: fewer windows cluttering up my workspace ;-) marmosets, Bryan ps - there's a very good howto for the ua-25 under linux using alsa on the alsa wiki: http://alsa.opensrc.org/Edirol_UA-25 On 2007-05-04 16:57:49, "David F. Place" <[EMAIL PROTECTED]> appears to have written: > Thanks, Bryan. The Edirol UA-25 looks good and the price is right. > Did you have any trouble getting it to work under linux? I noticed that > the manufacturer only supplies drivers for Windows and Mac. > > On May 4, 2007, at 10:34 AM, Bryan Jurish wrote: > >> moin David, >> >> I just recently acquired an Edirol UA-25 with which I'm quite happy (2 >> channel analog|digital audio I/O, MIDI). >> --Bryan Jurish "There is *always* one more >> bug." >> [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology > > ___ > (---o---o-o-o---o-o-o( > David F. Place > mailto:[EMAIL PROTECTED] > > > > -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] USB Sound "card"
moin Robert, it would appear so -- check out the site Frank mentioned a few iterations ago in this thread: www.qbik.ch/usb/devices/ marmosets, Bryan On 2007-05-04 19:29:00, "Atwood, Robert C" <[EMAIL PROTECTED]> appears to have written: > Are other 'Edirol' devices also working nicely with ALSA ? -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] converting (hebrew) text to numerical values?
morning Cyrill, Well, the most elegant way to convert back and forth between numerical (ASCII-like) values and text is Martin Peach's string patch to the pd sources (search the PD-dev archives for "string type for pd"). If you don't feel like going that deep, you can use my [any2string] and [string2any] externals (in CVS, or from me at www.ling.uni-potsdam.de/~moocow/projects/pd). Alternatively, you could split symbols into single characters using [symbol2list] from zexy, and then map these to numbers however you want (e.g. with [index] from zexy, PDContainer, pool, [gfsm_alphabet] from gfsm, etc.) You can do character classification (and even substring classification) with python (in which case you don't really need the string or indexing stuff), or with a simple finite state transducer (gfsm again), although if you're just interested in differentiating between consonants & vowels, you're probably better off just using [route] here... marmosets, Bryan On 2007-05-11 21:33:29, Cyrill <[EMAIL PROTECTED]> appears to have written: > Hi list > > I am willing to set up a patch that could convert letters to numerical > values, so i could use > converted text to send data to other patches (and then produce sound). My > problem is that i want > to work with hebrew, and i want pd to be able to differenciate between > consonants and vowels, and > maybe even to be able to recognize roots within the word. As I am quite a > novice concerning pd, I > have no clue about the most efficient way to convert letters into values, and > i dont even know if > it is possible within pd? > > Any advice will be greatly appreciated. > > Shalom > > Cyrill -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd and Edirol UA-25
moin Ede, moin list, Well, I'm successfully running both MIDI and audio off the UA-25, also on debian (mostly) etch, and a ThinkPad T42... First of all, don't use OSS (emulation) -- I've had no luck here with the UA-25 in "advance mode" and Pd; as you say, probably due to 24-bititude. Do you have an ~/.asoundrc defined, and if so, what's in it? If you're choosing from the pd "Audio Settings" menu, grab the "UA-25 (plug-in)" entries, rather than one of the "hardware" entries. Also, I've had to run pd with the "-rt" switch (which required getting realtime capabilities patches working: urgh) when using ALSA directly, otherwise I get audio pops and eventual "tried but could not sync" errors. fyi, I run pd here with: [EMAIL PROTECTED]:~$ cat `which pd-ua25.sh` #!/bin/sh ( pd -rt -r 48000 -alsa -channels 2 -audiodev 6 "$@" & ) ( sleep 5 ; aconnect-usb2pd.perl; jack-chrt.sh ) ... where "aconnect-usb2pd.perl" does some magic with 'aconnect', and the (badly named) 'jack-chrt.sh' messes around with some scheduling priorities. Important to note: - pd's sample rate should probably match whatever you've chosen on the ua-25 - use alsa. - for me, "-audiodev 6" is the 6th entry in the drop-down list of audio devices I get with the ua-25 plugged in (under normal circumstances), labelles "UA-25 (plugin)". good luck, Bryan On 2007-05-29 14:35:50, Ede Cameron <[EMAIL PROTECTED]> appears to have written: >After reading on the list about Edirol UA-25 I went out and got > one on run on Debian. I can get sound when running in standard mode > or midi in advanced but can't get both. I read on the list that some- > one is running both midi and sound. Problem is the UA-25 seems to > force 24bit in advanced mode which Pd won't run at or is there a way > to get around this. > Debian Etch > Power Book 1.5 > Edirol UA-25? -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd and Edirol UA-25
moin Robert, On 2007-05-30 17:15:06, "Atwood, Robert C" <[EMAIL PROTECTED]> appears to have written: >> -Original Message- >> On Behalf Of Bryan Jurish > ... > >> run pd with the "-rt" switch (which required getting realtime >> capabilities patches working: urgh) when using ALSA directly, >> otherwise >> I get audio pops and eventual "tried but could not sync" >> errors. fyi, I >> run pd here with: >> >> [EMAIL PROTECTED]:~$ cat `which pd-ua25.sh` >> #!/bin/sh >> ( pd -rt -r 48000 -alsa -channels 2 -audiodev 6 "$@" & ) >> ( sleep 5 ; aconnect-usb2pd.perl; jack-chrt.sh ) >> > > I don't quite follow: are you using JACK or the ALSA connection from pd? > Or you mean jack-chrt is badly named because it's not actually doing > anythign wth JACK? I meant that the script is badly named because it doesn't do anything with jack (well, to be totally honest, it might tweak jack's priorities if it finds a jackd running, but I'm not usually running it these days). I've tried using jack, even gotten things working, but my experiences to date with pd audio over jack have been less than fantastic, so I haven't put too much effort into it (contrast with the desktop, where I need/want to run ardour, but that's a different animal altogether). As I recall, the tests I ran with jack and the ua-25 all worked pretty well, but jack likes to complain when you use the alsa plugin layer "plughw:2,0" or whatever. I also used to get subtle but audible pops every 30 sec or so using jack, and I never figured out why... maybe it's gone now ;-) > I was about to get a UA 25 so am quite interested in how this works. > With the builtin (intel HDA) I get pops when using JACK but not when I > use the ALSA output . I did not get the pops with a different > application, when using JACK, but just when using PD and JACK .. Though > I've not exhaustively tested all applciations yet. But, I really want to > get the sound stream from PD into another application and via JACK seems > like the simplest way. ... attached is a relevant message I just received off-list which looks as if it was intended for this thread ... marmosets, Bryan On 2007-05-30 21:45:44, Olivier Heinry <[EMAIL PROTECTED]> appears to have written: > Hi, > > here is my running set up for the UA 25 on debian lenny/sid, no kernel > patch (2.6.18), Alsa compiled via the module-assistant: > > interface in advance mode @48k > > qjackctl runs with the following: > server : jackd, driver alsa > Realtime, soft mode & force 16bit mode ticked > priority 89, frames/period 256, rate 48k, periods/buffer=3 > dither none > audio : playback only > latency=16ms > > pd started as follow: > > pd -r 48000 -rt -jack -audiodev 1 (or whatever your setup, 0 being the > intel chipset #) > > Midi managed through qjackctl, just fine! > > ++ > O. -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Voice Synth
moin Roman, moin all, On 2007-06-02 11:53:21, Roman Haefeli <[EMAIL PROTECTED]> appears to have written: > but i couldn't find a help file. also when i create it, i get the > message: > > ratts: Realtime Analog Text-To-Speech externals v0.04 by Bryan Jurish > ratts: Based on text-to-speech code by Nick Ing-Simmons and Jon Iles > ratts: and PD external code by Orm Finnendahl and Travis Newhouse > > but the object doesn't get any inlets nor outlets. maybe you can tell us > a bit more about this external? Since Georg has already plugged my site (thanks, Georg!) , I will refrain from doing so at this juncture. [ratts] is just a dummy object which causes the whole library to be loaded. I used to be (actually, I still am) of the opinion that every external *library* should be dynamically loadable (which they are), and that it should be possible for any given abstraction to specify the libraries it requires by placing library-named objects (e.g. [zexy], [ratts], etc.) onto its canvas. Unfortunately, in my case, this practice has lead to much wailing and gnashing of teeth in particular with respect to pd-0.40.x and flext-based externals. Don't ask me why. If you grab the "official" ratts distribution, you should have a help-file ratts-help.pd for [ratts] which gives you an overview of the various objects and abstractions in the library. If you just want pd to talk, check out the "ratts~" abstraction: text in, speech signal out. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Voice Synth
moin Pall, moin list, Many apologies that the ratts help files seem to be less than entirely intuitive to first-time users; in my defense, I can only say: "sheesh, man, if you folks think the ratts pd API is poorly documented, y'all should see the rsynth code"... ok, now that I've gotten that out of my system (no flame intended, honestly): do you have an immediate suggestion as to how I could improve things? I realize that a ratts chain has more user-settable parameters than you can shake a proverbial stick at, but the defaults should be sensible (if you want something that sounds vaguely like human speech), and playing with those strange animals is half the fun ;-) I included the 'ratts~' abstraction so that users could get an idea how all those separate objects work together and/or just "make pd talk"; and I rather hoped that the 'ratts-help.pd' help patch would suffice for an overview of the objects in it... oh well... marmosets, Bryan On 2007-06-02 15:49:43, Pall Thayer <[EMAIL PROTECTED]> appears to have written: > Hi list, > > I've toyed around with Ratts quite a bit and when you do have the help > files it makes everything seem more complicated than it really is. So, > here's a little patch that contains the bare essentials that you need to > do start experimenting with Ratts: > > ratsass.pd: [snip] -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Voice Synth
moin Georg, moin list, On 2007-06-02 12:34:18, Georg Holzmann <[EMAIL PROTECTED]> appears to have written: > Hallo! > > Bryan Jurish is the speech expert in pd world ;) ... you can find all > his stuff here: http://www.ling.uni-potsdam.de/~moocow/projects/pd/ Thanks for plugging my site Georg... saves me some typing ;-) > There are the ratts and flite externals. I think he also made an > external for the mbrola speech synthesizer, but did not release it ... Sorry, never made an mbrola external -- mbrola is closed-source free-as-in-beer-ware. Somebody (I forget who) wrote a MAX external for mbrola a few years back, and unto him did I praise and extol the wonders and glories of flext, but lo, the release was binary, and it was only unto the Mac, and there was much wailing and gnashing of teeth. I did make an ugly-hack patch at one point using ext13 (pipein~?) to talk to mbrola over named fifos, but it never worked particularly well. I have another (far, far uglier but at least functional) system that looks like (pd <--(OSC)--> perl <--(TCP)--> festival --(system calls?)--> mbrola --> temp files --> pd), but the guts are all freely available (SayWhat is the perl part, festival works "out-of-the-box", and my patches basically require my entire patch library, which I'm too lazy to package at the moment). If anyone is terribly interested, I can tar up my whole pd patch library and point you at the relevant patches. > Yes, for the pd radio I used the flite external, which is quite okay but > only english ... It's allegedly possible to compile a flite library for any festival language-model built with the festvox tools (note: this does not include German: AFAIK the only festival support for German is from IMS Stuttgart, they've stopped supporting it, and I personally have never gotten it to compile, even after much wailing, gnashing of teeth, etc.) I'm not sure how well the pd flite interface actually supports multiple languages -- I've only ever tested it with the default english models. It should be pretty straightforward to compile & link it against an alternate flite library though. If anyone succeeds, I'm happy to discuss how to go about generalizing the build procedure. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mbrola for pd?
moin fp, Also see Tim Redfern's [flite~] (threaded) at http://eclectronics.org/publish/flite~/ and try [ratts] from http://www.ling.uni-potsdam.de/~moocow/projects/pd/ratts-0.08.tar.gz if you want to make pd sound like your old Speak'n'Spell (oops, I'm dating myself)... I recently heard from Nicolas d'Alessandro, author (I think) of the mbrola wrapper for max, who referred to himself as "maintainer of the MBROLA for Max and Pd external". You might check his web page http://www.nicolasdalessandro.net/ for availability of the pd wrapper. IIRC, any mbrola wrapper for pd will have to be a binary-only distribution, since mbrola isn't available either as source or as a dynamic library, but it's been a few years since I last looked into it, so maybe things have changed in the meantime... marmosets, Bryan On 2010-06-10 16:59:26, fp appears to have written: > hi > i know there is one for max and something on sc so i was wondering: is > there a pd object for mbrola? > alternatively, any other speech synthesis implementations usable from pd? > thanks -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] plugin~ external
morning all, On 2010-06-14 11:36:44, IOhannes m zmoelnig appears to have written: > On 2010-06-13 15:15, patko wrote: >> " man, the fender stratocaster is a professional guitar" > > so what would be the guitar brand/model where someone would say: > " man, this is a professional guitar"? The name "Steve Klein" comes to mind (http://www.kleinguitars.com)... but bear in mind that I'm a bit biased as a Frisell devotee. OTOH, Robert Johnson produced some phenomenal music on what sound like serious klunkers (although the recording technology left a lot to be desired too)... so what was the point again? :-P marmosets, Bryan ps - sorry sorry sorry, I just couldn't resist pulling this thread even further OT ;-) -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] class_sethelpsymbol (was: [folder] external?)
morning all,
On 2010-06-25 20:43:38, Hans-Christoph Steiner appears
to have written:
> I'm not aware of the rules that you are talking about.
huh?!
I clearly and distinctly recall that you (Hans) mentioned to me off-list
in 2008 that use of class_sethelpsymbol() was deprecated for pd-extended
("it is best not to use class_sethelpsymbol() at all" [for pd-extended])
and recommended that I remove those calls from my code (to be fair, you
offered to make the required changes yourself to the external which
brought my use of class_sethelpsymbol() to your attention). I know that
I added a few #ifdefs to some of my own externals in order to avoid
those calls (and others) for pd-extended builds. I assume that the
"changed rules" to which Yves refers in this context are simply the
deprecation/breaking of class_sethelpsymbol() for pd-extended, versus
its fully functional public-API status in pd-vanilla (@Yves: feel free
to correct me if I'm mistaken here).
> One thing I do
> know is that you don't need to use class_sethelpsymbol() for a object
> called [playlist] unless the help patch is called something other than
> playlist-help.pd.
> So for 'unauthorized', all of the help patches are named after the
> objects, so class_sethelpsymbol() is unneeded and redundant.
Indeed. The same holds (these days) for 'moocow'. I still feel that
this discussion is relevant, though.
im(ns)ho, the problem is not so much a matter of the "official" (read
"conventional") help-file naming scheme, but rather help files for class
aliases (i.e. class-names allocated by class_addcreator(), which is also
deprecated / broken in pd-extended), and external "families" (e.g.
[any2bytes], [bytes2any], [any2wchars], [wchars2any]): any case in which
multiple classes can/should/must share a single intuitive help patch.
Such shared help patches however must be needlessly duplicated (e.g.
copied on install) to conform with a strict conventional help-file
naming scheme as apparently (formerly?) required by pd-extended, which I
find inelegant as a programmer and a pain in the wahooni as an external
maintainer. Don't get me started on multi-object libraries... just my
€0.02 ...
marmosets,
Bryan
ps - just to add yet another method for reading directory contents to
the ever-growing list attached to the original (wobbling) thread:
there's also [readdir], which gives you some filesystem information too
(or perhaps [moocow/readdir] for pd-extended; I don't really know since
I use pd-vanilla for reasons which may or may not be apparent)...
> On Jun 24, 2010, at 10:44 PM, ydego...@gmail.com wrote:
>
>> yeh, exactly...
>>
>> but as people change rules about help files without prior notice,
>> i'm just bored of handling that kind of issue
>>
>> the initial idea of sethelpsymbol was that you could put as help file :
>> comment-peigner.la.giraffe.pd as help file and
>> nobody would have bothered you for that...
>> but freedom is gone with obscure rules...
>>
>> ciao,
>> sevy
>>
>> Jonathan Wilkes wrote:
>>> Oh, I thought I was using a nightly build but I wasn't. If I add
>>> "playlist-help.pd" to extra/unauthorized I see it finds it just fine.
>>>
>>> Thanks,
>>> Jonathan
>>>
>>> --- On *Thu, 6/24/10, ydego...@gmail.com //* wrote:
>>>
>>>
>>>From: ydego...@gmail.com
>>>Subject: Re: [PD] [folder] external?
>>>To: "Jonathan Wilkes"
>>>Cc: "Kim Cascone" , "pd-list"
>>>Date: Thursday, June 24, 2010, 11:28 PM
>>>
>>>
>>>
>>>the problem is absolutely not that,
>>>this is perfectly correct..
>>>
>>>problem is that playlist-help.pd is not included in pd-extended ..
>>>
>>>Jonathan Wilkes wrote:
>>>> A different issue:
>>>>
>>>> Line 1019 of playlist.c:
>>>> class_sethelpsymbol(playlist_class, gensym("playlist.pd"));
>>>>
>>>> But the help patch is "playlist-help.pd," so pd apologizes:
>>>> sorry, couldn't find help patch for "playlist.pd"
>>>>
>>>> -Jonathan
--
Bryan Jurish "There is *always* one more bug."
jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] benevolent dictator?
morning all, My technique (read: "hack") for auto-loading libraries in vanilla has been just to instantiate an object [foo] in order to load the library foo.pd_linux. This causes error messages for some libraries (notably xsample, which I use a lot), but works well with the vanilla loader. I guess we can't dictate that every library xyz.pd_linux register a class 'xyz', but that's the simplest way I've found of loading libs. Of course, you can't declare inter-library dependencies this way (that I know of), but it's a start... marmosets, Bryan On 2010-07-13 12:26:42, Frank Barknecht appears to have written: > Hi, > > On Tue, Jul 13, 2010 at 11:48:18AM +0200, Roman Haefeli wrote: >> Personally, I'd prefer to not auto-load anything at all, which would >> also encourage a nice patching style with explicitly loading the >> required libraries. I'd be interested to hear what others think about >> the matter. > > I would love a proper way for Pd vanilla/core to load libraries into > abstractions. I know of [import] but most of my abstraction libraries > target vanilla installs, too, so I cannot use it. And [declare] > currently is designed for top-level _main.pd-style patches only, so > there's no way to really preload list-abs in RTC-lib-abstractions for > example. > > If this issue is solved, the problem of autoloading becomes almost moot. > Well, there still are some issues like the sad omission of "sssad" in > Pd-extended which is not shipped at all but such things are > comparatively trivial to fix. > > Ciao -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problems with "pool" object
moin João,
Not that I think this will be of much help, but when I had similar
flext-related crashes ("free(): invalid pointer") in the past, it turned
out to be due to missing initialization code in the constructor. I
really don't believe [pool] suffers from this problem (we would have
heard about it before now), but cf. my signature :-/
Anyhoo, I found it helped (but didn't solve all problems) to compile the
flext externals in "static debug" mode -- of course, this causes some
memory bloat and slows things down a bit, but it might get you running
on your target architecture...
marmosets,
Bryan
On 2010-08-24 11:30:30, João Martins appears to
have written:
> Nothing is as simple as it looks, as I'm learning by the minute.
> With the latest release of Pd, turning off Gem does not allow "pool" to
> work properly, and I get exactly the same error message.
> This leads me back to "pool" in itself.
> Compiling all of "flext" really seems a daunting task, but I think I'll
> give it a go, if no one comes up with a better suggestion. ;)
>
> Thank you all.
>
> João Martins
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] markov chains?
morning, there are some utilities for using finite state automata as (hidden) markov models in the [gfsm] suite (namely the [gfsm_markov] abstraction): http://www.ling.uni-potsdam.de/~moocow/projects/pd/pd-gfsm-0.05-2.tar.gz (should also be in pd-extended, unless it has broken since I last looked). There are also some simple examples of using [gfsm] to generate markov sequences in the slides from my talk at pd~convention 2004: http://www.ling.uni-potsdam.de/~moocow/pubs/pdconv04talk.pdf marmosets, Bryan On 2010-09-30 20:45:22, "L.J." appears to have written: > looking for implementations of markov chains i found > http://footils.org/cms/weblog/2009/may/23/markov-chains-pure-data/ > but the page seems to be gone? > > can anybody point me to some simple markov patches? > appreciated > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard encoding of pd files in each system?
moin all, @hans: thanks for the vote of confidence :-) @João: ... for converting strings (lists of bytes, represented as pd floats) to floats (as in pd floats, a la C strtof() & friends) you can do some sick bad ugly and wrong things using [bytes2any] in conjunction with [locale] (e.g. by dynamically re-setting LC_NUMERIC) ... but maybe that wasn't what you meant... marmosets, Bryan On 2011-01-26 21:06:35, Hans-Christoph Steiner appears to have written: > > Pd < 0.43 is probably something like ISO-8859-1 or perhaps UTF-8, Pd > 0.43 is UTF-8. UTF-8 or ISO-8859-1 will both be fully ANSI if only the > standard ASCII chars are used, i.e. no ü, ã, é, etc. > > For converting, I like moocow/any2bytes and moocow/bytes2any. > > .hc > > On Jan 26, 2011, at 5:17 AM, João Pais wrote: > >> Hi, >> >> I was curious to know what is the standard encoding of pd files in >> each operating system. According to Notepad+, in XP is ANSI. >> >> Or a followup question, which format is better for pd to read a string >> of characters and convert it to floats? ANSI seems the be most >> reliable here where it comes to interpreting the data, although utf8 >> without BOM renders them in the symbol atom more accurately. >> >> The reason I'm asking is because I'm working with converting ascii >> characters to their float value. >> >> If anyone wants, I can send a small test patch to try out. >> >> João >> >> -- >> Friedenstr. 58 >> 10249 Berlin (Deutschland) >> Tel +49 30 42020091 | Mob +49 162 6843570 >> Studio +49 30 69509190 >> jmmmp...@googlemail.com | skype: jmmmpjmmmp >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > > > > If you are not part of the solution, you are part of the problem. > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard encoding of pd files in each system?
moin all, fwiw, I'll add my vote in favor of getting Martin's [str] / blob patch into pd vanilla. iirc, Miller has indicated in the past that he feels this sort of thing should be done using arrays. There are a couple of proof-of-concept objects (not compiled by default) in pdstring (moocow/pdstring for pd-extended users) that use arrays, but I wasn't satisfied with this approach for two reasons: 1) If you treat the array internally as a string of bytes (e.g. char*), then: (A) you must constantly cast and re-cast the data (B) you must scale all size attributes (e.g. for re-allocation) by 1.0/sizeof(t_float), so to get an accurate byte length that is not a multiple of sizeof(t_float), you need to actually store that length additionally somewhere else (C) saving array data with a patch and re-loading can cause data loss (float truncation may mess up raw byte values) (D) it's not really portable (byte order problems with load/save) 2) If otoh you let the array remain a t_float* and just assign the floats byte ((unsigned) char) or even wide character (wchar) values, then: (A) you potentially waste a lot of memory (strlen(str)*(sizeof(float)-1) bytes) (B) I/O: if you read a string as a (char*) -- e.g. from a file, socket, external library, etc. -- or if you need a pd-array-string as a (char*) -- e.g. for an external API call -- then you have to explicitly convert it, which means allocating some memory (maybe defining a static local buffer to avoid malloc() calls), and iterating over the string (rsp. over the array), which is O(N) time and space, and is annoying for long strings and/or frequent calls (C) if you really want to store your string data in an array, you can use [str] or [pdstring] together with e.g. [tabdump] and [tabset] from zexy, which just makes the conversion overhead explicit. I think there are workarounds for both techniques, but not without patching the pd core code, and if we're going to patch the core code, we might as well take a patch that does the job "right" (i.e. Martin's)... just my €0.02 ... marmosets, Bryan On 2011-01-28 09:59:39, Roman Haefeli appears to have written: > On Wed, 2011-01-26 at 22:54 +0100, João Pais wrote: > >>> For converting, I like moocow/any2bytes and moocow/bytes2any. >> I think I had a look at it as well. do you have any comparative reason for >> that one instead of the other? or it was just the first one to get to you? > > One important thing to know is that [mrpeach/str] only works with > Pd-extended, but not with Pd-vanilla as it requires some modifications > to m_pd.h. > > Btw @Martin: Do you think it's time again to to try to get the blob > support into Pd-vanilla? I think that [str] would be utterly useful also > in vanilla and it didn't seem to have caused any problem in Pd-extended, > did it? > > Roman > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- *** Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:jur...@bbaw.de *** ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd quine?
exit(1) for now, although feel free to ask me again next week... ;-) On 2011-01-28 21:33:34, Mathieu Bouchard appears to have written: > On Fri, 28 Jan 2011, Tedb0t wrote: > >> The thought just occurred to me... Has anyone ever made a Pd quine? >> Sounds like an interesting challenge... > > Using Pd's save feature or not ? > > Pd has a natural advantage in that it contains such a feature, but if > that feature is ruled out, then a self-replicating programme is probably > a lot lengthier and complicated than in the average language... though > this could an interesting challenge. > > will Bryan and Claude compete with each other on this one ? :) > > ___ > | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard encoding of pd files in each system?
moin Mathieu, moin all, On 2011-01-29 17:12:02, Mathieu Bouchard appears to have written: > On Fri, 28 Jan 2011, Bryan Jurish wrote: > >> iirc, Miller has indicated in the past that he feels this sort of >> thing should be done using arrays. > > But a feeling is but a feeling. Now, how about a justification ? > But that's not the sort of thing one gets from Miller often. > >> (B) you must scale all size attributes (e.g. for re-allocation) by >> 1.0/sizeof(t_float), so to get an accurate byte length that is not a >> multiple of sizeof(t_float), you need to actually store that length >> additionally somewhere else > > sizeof(t_float) is always a power of two, isn't it ? I haven't heard of > anyone using 80-bit or 96-bit floats as t_float or t_sample. > > thus a size stored as float will be accurate up to 16777216. > > This is regardless of whether you store size*4, size, or size/4 : floats > are quite scale-independent, but are perfectly so when the scalings are > powers of two (provided you don't overflow by scaling by pow(2,128) or so) > > I think you could read a bit about the IEEE-754 standard : > http://en.wikipedia.org/wiki/IEEE_754 > > But especially some kind of short, direct tutorial that will make it > obvious what won't be rounded and what will be : > http://kipirvine.com/asm/workbook/floating_tut.htm Yup, all freely stipulated. My issue was not so much with the use of floats qua floats to store size data, rather the necessity of storing size data *in addition to* the size reported by the array itself. In this scenario, we're blatantly re-casting the array's (t_float*) into a (char*) and reading/writing raw bytes. But maybe we don't want C-style NUL-terminated strings, but rather perl-ish (or Berkeley DB-ish) strings which admit embedded NULs and store their length in an additional dedicated attribute (usually an unsigned int, but sure, we could use a float if we wanted). The problem is that if we (ab)use the existing garray API (garray_getfloatarray(), garray_npoints(), garray_resize()) to do this, then the sizes reported for the array may be longer than the size of the string. My system uses 32-bit floats, and say I want a string "foo" (without terminating NUL). Well, "foo" takes up less than the space of 1 float (3 bytes < 4 bytes), but garray_npoints() for a float array of size 1 is going to give me 1, and 1*sizeof(float) = 4 > 3, so if I want to implement strings this way, I've got to fiddle around with some additional convention for storing their actual length. It looks as if the whole garray stuff is defined abstractly enough to handle more than just "plain" float arrays, but I haven't dug deep enough to figure out what exactly those (t_template*)s are all about or how I might be able to (ab)use them... >> (C) saving array data with a patch and re-loading can cause data loss >> (float truncation may mess up raw byte values) > > for integers, all values from -100 to 100 will be correctly > saved (those two bounds will be encoded as -1e+6 and 1e+6, and all the > rest will look like plain integers). Yes. See above re: char *s; garray_getfloatarray(a,size,(float **)&s); >> (D) it's not really portable (byte order problems with load/save) > > byte order problems won't happen with floats saved as text. they will > happen with floats saved as binary. they will also happen with UCS-2 > text saved as two floats per code point (no matter how you save the > floats), but if you use UTF-8 instead, or if you use > one-float-per-codepoint, that aspect will be safe. No. See above. Messing about with typecasts is very implementation-dependent, and afaik IEEE-754 doesn't define how its components are to be implemented, only the formal criteria an implementation must satisfy. >> 2) If otoh you let the array remain a t_float* and just assign the >> floats byte ((unsigned) char) or even wide character (wchar) values, >> then: >> (A) you potentially waste a lot of memory >> (strlen(str)*(sizeof(float)-1) bytes) > > In 2011, wasting a lot of RAM is not a problem. Wasting too much RAM can > be a problem, and that's very relative, as quite often, the solution is > to wait until RAM is less expensive. I like the idea of not wasting any > RAM, but I recognise that this is because I got used to think about ways > to reduce waste, not because it's always good to worry about it. > > Text is usually a lot smaller than video. It's not uncommon for me to > store a buffer of 64 frames of video in colour. In 640x480, that's over > 55 megs, and that's tiny compared to the total amount of RAM the > computer has. How often do you need that
Re: [PD] Building Externals
morning all, On 2008-10-13 20:44:56, Hans-Christoph Steiner <[EMAIL PROTECTED]> appears to have written: > On Oct 13, 2008, at 7:20 AM, IOhannes m zmoelnig wrote: >> carmen r wrote: >>> and broke up the modularity of the makefiles >> this has basically been my arguing for ages. >> >> i would very much like to revamp the entire build-system, but haven't >> had the time to do it. >> if several people are interested in doing so we could form a taskforce >> and just do it. > > Sounds good to me. Likewise. >>> oh well, unsubscribing. have fun in your broken paradise >> oh well, your zeal was shortlived then >> let me know if you are still interested in making a better world. > > Wow, that was a waste of everyone's time. Just come in and bitch at > a lot of people, then bail. I think it falls under "free and open exchange of ideas" ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with Delta 1010LT?
morning Jaime, I have the same card in my desktop here under debian testing/unstable, and have also successfully used all the analog in- and outputs with pd. The only potential causes for your problem that occur to me are "stupid" ones that you've probably already checked, e.g. routing problems on the card [have you run "envy24control" and checked that the input levels (tab page "analog volume") are all up where they should be?] Did you start pd with "-channels 8"? I also vaguely remember hearing of problems with the alsa mixer API (alsamixer, amixer, etc.) for envy24 cards -- the conventional wisdom seems to be: "avoid ALSA's mixer and use only envy24control for this card". You might also check whether your distro is doing something sneaky like calling "amixer" behind your back when the driver module (snd_ice1712) is loaded (e.g. as a post-install operation declared in /etc/modules.conf)... other than that, I'm pretty much out of ideas... marmosets, Bryan On 2008-11-09 09:06:25, "Jaime Oliver" <[EMAIL PROTECTED]> appears to have written: > Hello all, > > I have an M-Audio Delta 1010LT in Fedora 8. I never installed any > drivers since it seemed to work right out of the box. I have managed to > use the 8 channels OUT, but can't get a signal into pd in any of the 8 > channels IN. Has anyone else seen something like this? > > best, > > J > > -- > Jaime E Oliver LR > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > www.realidadvisual.org/jaimeoliver > <http://www.realidadvisual.org/jaimeoliver> > www-crca.ucsd.edu/ <http://www-crca.ucsd.edu/> > www.realidadvisual.org <http://www.realidadvisual.org> > > 858 202 1522 > 9168 Regents Rd. Apt. G > La Jolla, CA 92037 > USA -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Chicago Patching Circle
morning all, Deja vu. It so happens that I'll be in Chicago visiting family for 3 weeks starting December 18th, and would certainly be interested in dropping in on a Pd-related event in my old stomping grounds (spent a good deal of my undergraduate time in the Heartless and in the now-defunct No Exit); so if the event gets pushed back another week or so, count me in -- of course, that's encroaching on yet another holiday, so no worries if it doesn't pan out... marmosets, Bryan On 2008-11-10 19:31:23, "Mike McGonagle" <[EMAIL PROTECTED]> appears to have written: > It seems that this should become its own thread > > So, I still have not heard about the bar, but it would be nice to see > what times that people would be interested in holding this event. I > would think that with Thanksgiving coming up, that we shouldn't begin > until after that, maybe the first or second Sunday of December. That > would be either the 7th, or the 14th. And as I mentioned before, early > afternoon might be the easiest times to acquire, as they don't have > any regularly scheduled events. (They do have some bands on Sunday > nights, but that is not til after 9.) > > Just so everyone knows where this is: > > Red Line Tap > 7006 N Glenwood > Just off the Morse El stop (if you exit to the North onto Lunt, it is > a half block from there) > > http://maps.google.com/maps?f=q&hl=en&geocode=&q=7006+N+Glenwood,+Chicago&sll=37.0625,-95.677068&sspn=58.337319,94.833984&ie=UTF8&z=17&g=7006+N+Glenwood,+Chicago&iwloc=addr > > Mike > -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] speech recognition for pd
moin patrick, this is excellent! is the code available somewhere? marmosets, Bryan On 2009-01-13 16:58:21, patrick appears to have written: > hi all, > > last night, i did a bridge between sphinx3 and pd. sphinx3 is an open > source speech recognition software. > > have a look at the demo > http://www.vimeo.com/2814913 > > i am looking for help for optimizing or even better making an external > for it. > > 1) working on linux only for now. > > 2) using shell to call a python script (py/ext is crashing when import > _sphinx3) > > 3) communication between the python script and pd via open sound control > (mrpeach) - i like this solution, cause i can use the same script to > have speech recognition in blender or other osc compatible software > > 4) using shell again to call sox (for converting the soundfile to raw). > is it possible to write a raw soundfile in pd (1 channel, signed, 16000 > (samplerate))? > > 5) dynamic patching with send pd-$0.sphinx (obj 20 20 $voicerecognition) > - would like to be able to connect objects together, need to learn more > about dynamic patching > > 6) it's possible to make a custom dictionary, for now i will create one > for basic stuff (http://wiki.puredata.info/en/Category:vanilla) > > 7) tested with two big accents : french (me) and japanese (my girlfriend) > > pat -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] request for objections: any2string -> unsigned char
morning all, Would anyone object if the [any2string] semantics were changed so that only "unsigned char" values in the range (0..255) get output, rather than (as is currently the case) "signed char" values in the range (-128..127)? For reasons to do so other than the purely aesthetic, see Roman's recent sourceforge report wrt. [any2string] (Bug #2501709, http://sourceforge.net/tracker/index.php?func=detail&aid=2501709&group_id=55736&atid=478070). speak now or forever live with the consequences, etc. etc., Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
moin Mathieu, moin all,
On 2009-01-15 16:33:03, Mathieu Bouchard appears to
have written:
> On Thu, 15 Jan 2009, Bryan Jurish wrote:
>
>> Would anyone object if the [any2string] semantics were changed so that
>> only "unsigned char" values in the range (0..255) get output, rather
>> than (as is currently the case) "signed char" values in the range
>> (-128..127)?
>
> What's important to me is that the Pd user does not struggle with making
> pd interpret UTF-8 variable-length encoding, and instead struggles with
> making pd work with lists of characters, which is already enough work
> anyway.
Agreed (in principle at least)... At the risk of repeating myself, I
wrote [any2string] and [string2any] as quick ugly hacks to get some sort
of rudimentary string handling in pd. Roman mentioned a few other
externals (e.g. [comport]) which expect unsigned raw byte values, which
I think is sufficient reason to change the (byte-oriented) conventions
of [any2string].
Unicode might be more immediately intuitive to most users, but when it
comes down to it, byte-strings are IMHO the more basic representation (a
char* is still a char*, even in this post-unicode world). Some of us
even still use non-unicode encodings by default. A good string handling
mechanism should have a good general default representation (e.g. as
UTF-${MachineWordBits}), but should likewise allow access to "raw" byte
strings, and be able to accommodate various encodings. Not that I'm
really hankering to write any of that, mind you ;-)
Perhaps a better name for the external as I think of it would be
[any2bytes]. I'm perfectly willing to cede the "string" name to
something better (Martin's string patch comes to mind), but that's just
a labelling issue (and since variable names are arbitrary, and externals
are in some sense variables, external names must therefore also be
arbitrary ;-)
> I like that [list length] gives me the number of characters and
> not the number of bytes, because the latter is rarely significant.
... except if you're building rsp. reading a persistent index for a
large file, in which case tell() & seek() are likely to be a wee bit
faster than parsing and counting variable-length-encoded characters ...
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
moin Mathieu, moin all, On 2009-01-15 20:45:13, Mathieu Bouchard appears to have written: > On Thu, 15 Jan 2009, Bryan Jurish wrote: > >> byte-strings are IMHO the more basic representation (a >> char* is still a char*, even in this post-unicode world). > > What happened is that people switched to UTF-8 instead of some > fixed-size encoding because many apps that assume that a character is a > byte will work anyway. UTF-8 also does a pretty good job of compactly representing latin character sets for natural language data, where non-ASCII characters tend to be relatively infrequent anyways. UTF-16 and UTF-32 are pretty wasteful in these cases. (Of course, I'm biting my own tail with this point, since the [pdstring] representation is even more wasteful than UTF-32 ;-) > Just don't ask those apps to say how many > characters there are in a string though. You have to pretend that all > the "special" characters are pairs of characters instead (when they are > not triplets). Indeed. Ugly but true. > I gather that it'll take a long time before Pd gets unicode support... I suspect you're right. >> ... except if you're building rsp. reading a persistent index for a >> large file, in which case tell() & seek() are likely to be a wee bit >> faster than parsing and counting variable-length-encoded characters ... > > right. ... or calling malloc(), or doing pretty much any other low-level fiddly stuff ... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
moin again all,
On 2009-01-15 20:37:12, Mathieu Bouchard appears to
have written:
> On Thu, 15 Jan 2009, IOhannes m zmoelnig wrote:
>
>> so does anybody object to use an "unsigned" type rather than a signed
>> one?
>> expanding "uchar" to "uint" or whatever is no-work on the Pd-side of
>> things.
>
> It's not that, it's that if you have ü (u umlaut) taken from a UTF-8
> file, then do you treat is as 195 188, or as 252 ? That is, is it
> predominantly two bytes, or predominantly one character ?
To clarify: my position is that the most fundamental representation is
the raw byte string, so a UTF-8 'ü' would be represented as
bytes(encode("utf8",'ü'))={195,188}. Nothing stands in the way of
parsing unicode codepoint values from such a representation, to get
unicode_chars("utf8",{195,188})={252}.
OTOH, if the file were known to be encoded in latin-1, we'd have
bytes(encode("latin1",'ü'))={252}. Without knowing the encoding of the
source, there's no reliable way to determine which unicode codepoints
its raw bytes are representing (or even if the powers that be have seen
fit to define such codepoints), so I would argue against making unicode
the *only* available internal representation.
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
moin moin, On 2009-01-16 15:56:22, Mathieu Bouchard appears to have written: > you have to use Pd's lists, and then it's 64 or 128 bits per char. > > And then, in theory, Pd could adopt any internal rep, as long as file > I/O and socket I/O is done the way it needs to be done. ... which (if I understand correctly) pushes the whole encoding mess onto the I/O layer, which I believe (based on many many past headaches trying to get the encoding support of the perlIO layer to work transparently on in-memory strings) is The Wrong Way To Do It (TM). Precisely the I/O layer is "low-level" in my sense, which means it ought to be bytes only. Encoding-dependent "character" units are higher-level and ought to be independent of that layer. >>>> ... except if you're building rsp. reading a persistent index for a >>>> large file, in which case tell() & seek() are likely to be a wee bit >>>> faster than parsing and counting variable-length-encoded characters ... >>> right. >> ... or calling malloc(), or doing pretty much any other low-level fiddly >> stuff ... > > It doesn't matter much, as Pd patches wouldn't be doing malloc(). > Furthermore, I expect that you have or you would have a function for > converting a list to a C string in the proper encoding, so that externs > that want to use your strings don't have to do for(i=0;...) a[i]=b[i] > all of the time, but also because it's a good opportunity for > introducing optional encoding conversion. Leveraging vanilla pd means that I can't (easily) export any functions, since each external is supposed to be self-contained. Of course, it's easy to write such functions and offer them as "copy-in" replacements, or define function-body macros, etc. etc. ... to date, there have been no requests for such an API, and potential users have to write their own for-loops... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
morning all, On 2009-01-15 22:51:14, Hans-Christoph Steiner appears to have written: > As for the simple question of unsigned versus signed for any2string, I > have never heard of using negative values for chars, so it makes perfect > sense to me to use 0-255. That'll will give at least the full latin > charset. OK. I guess I'll make unsigned values the default for [any2string] then, postponing the issue of name change to [any2bytes] rsp. [bytes2any] to a hypothetical future in which the "string" suffix implies unicode or other non-byte-oriented representation. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
moin all, On 2009-01-18 19:41:06, Roman Haefeli appears to have written: > On Sun, 2009-01-18 at 13:46 +0100, IOhannes m zmoelnig wrote: >> Martin Peach wrote: >> i always thought that bryan's "pdstrings" was intended for purposes of >> linguistic processing (unlike a lot of your objects that are indeed >> targeted at transmission). > without having thought of what pdstring could be targeted to, i was > always looking for something targeted for transmission, i.e. to be > used together with [comport] or [tcp[server|client|send|receive]]. if > pdstring is not recommended, what is recommended then? well, without wanting to be trite, I have to say that think that "data transmission" and "linguistic processing" are pretty much synonymous. In fact, the original reason for writing [pdstring] was to enable me to transmit (pseudo-)natural-language data represented as lists of pd atoms as a stream of byte values over OSC (using zexy's [drip]), so I guess the "target use" is "transmitting (processed) character data" ;-) That said, I think the [pdstring] representation is just a way of fudging a string datatype into pd -- use it for whatever seems useful to you. The "string" part may (as Mathieu suggested) change to unicode in the future, but I've added aliases [any2bytes] and [bytes2any] for now. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] request for objections: any2string -> unsigned char
morning again all,
On 2009-01-19 15:19:04, Martin Peach appears
to have written:
> Bryan Jurish wrote:
>> well, without wanting to be trite, I have to say that think that "data
>> transmission" and "linguistic processing" are pretty much synonymous.
>
> Pretty much but linguistic processing is happening at a higher level
> than data transmission, and the 'character' used in language may be
> represented by more than one data transmission 'character'.
Well, speaking as a linguist, I guess I have to say that I don't think
meaningful "linguistic processing" can really happen at the character
level (even though that's almost invariably the starting point for NLP
programs), but that's just me getting pedantically OT. Sorry.
Of course you're right, and "characters" are intended to represent
linguistically salient units ("graphemes").
> With ASCII and its 8-bit relatives it's almost the same because the two
> kinds of character are the same, but unicode uses more than one data
> character per linguistic character.
Yup (well, sometimes it does... it's the curse of those darned
variable-length encodings again...)
> That's why I think there needs to be a distinction between the two types
> of 'string', and maybe two levels of objects to deal with them, like
> [unicode2byte].
I fully agree: we should distinguish between "byte strings" and
"(unicode) character strings". As for converting between character- and
byte-strings, there are a whole slew of encoding pitfalls to watch out
for. Converting between (say) a UCS-4 unicode character string and a
UTF-8 byte string is easy, but things get uglier if we want an old-style
8-bit encoding (other than latin-1) for the byte string...
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
[PD] Announce: pdstring v0.08 + locale v0.01
morning all, As of yesterday, a new version of [pdstring] is available on SVN and from me (http://www.ling.uni-potsdam.de/~moocow/projects/pd). Following the discussion ensuing from my recent "request for objections", I weaseled some wide-character support into the [pdstring] representation with new objects ([bytes2wchars], [wchars2bytes]) and abstractions ([any2wchars], [wchars2any]). The old [any2string] and [string2any] are now [any2bytes] and [bytes2any], with the old names still working as aliases. In order for the wide character support to do anything useful, you'll need to call setlocale(LC_CTYPE,...) to determine how byte strings are to be interpreted. For this, I've written a quick & dirty external [locale], which has stunning potential for disaster (see the help file for one scenario), but does what it should. I'm still toying with Miller's suggestion of array-based persistent strings, but I haven't found a good solution yet: either we access and re-interpret g_array's data vector (safe at runtime, but gets mangled on save & reload), or we're limited to 24-bit values which t_float can losslessly encode. The latter is more compatible with other pd tools ([tabread], [tabwrite], zexy's [tabset], [tabdump]), but the former would make wrapping C functions a lot more comfortable... ideas, anyone? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] japanese encoded chars in PD
morning all, On 2009-02-11 03:04:34, Hans-Christoph Steiner appears to have written: > On Feb 10, 2009, at 3:14 PM, august wrote: >>> august wrote: >>>> hey'aw. >> are there also objects for handling conversions between character >> encodings? Or, an object to convert between utf8 or UCS-2 and the >> unicode >> char code numbers that GEM takes? Well, there are [bytes2wchars] and [wchars2bytes] in the newest [pdstring] library, which convert between multibyte encodings such as utf8 and your C library's wchar_t, which if I'm not entirely mistaken is a system-dependent encoding, but at least here (linux, glibc), it looks a heckuva lot like UCS-4. >> Is there a default character encoding for PD messages? I assume it is >> LATIN1 because I have seen umlauts in comments before(I think). It >> doesn't look like I can make comments in UTF8 encoded chars. >> >> I have my char problems solved right now, but now as I discover more >> about the difficulties of character encodings and the treachery that >> ASCII has causedI am just curious. > > Its a weird bastard mix currrently of Latin1 and UTF-8. The Tk GUI can > handle UTF-8 and uses UTF-8 natively. The C side is basically Latin1 > but doesn't really check: Out of curiosity, I just checked with a variant of 'unibarf.pd' (attached as "barf-both.pd"), and for me, pd *does* display utf-8 strings correctly in message boxes (tested with umlauts äöü, as well as Greek πδ -- other characters can be tested with the [pdstring] help patches). Surprisingly (to me), I don't have to do anything special to get UTF-8 characters displayed correctly, but setting LC_CTYPE=en_US.UTF-8 causes a latin-1 message to be displayed improperly (characters disappear, but are still passed and present in raw byte form). Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an odd error message from Pd though: Pd: buffer space wasn't sufficient for long GUI string (repeated 3 times) ... this appears on stderr, rather than the console. I get the same message once for "barf-both.pd"; assumedly due to mis-parsing of the latin-1 message box(es). > This is something that I would really like to have working properly in > Pd-devel. Tcl/Tk is natively UTF-8, so it seems that we should support > UTF-8 in Pd. Anyone feel like trying to fix it? I don't understand > encodings so well. I don't know for sure, but I suspect one problem might be in the interpretation of user input -- I use latin-1 myself, so I can't judge whether the Tk GUI accepts UTF-8 input or not (I use [pdstring] or just hack the .pd file for my tests). If we want to be paranoid about things, we're likely to run into problems with symbols too; symbol identity (hash value and raw byte string) can change depending on whether the C internals use UTF-8 strings or not: this depends not only on what they get from the GUI, but also on how file data is interpreted, netsend/netreceive, etc etc... (mostly t_binbuf, I guess). UTF-8 should be largely safe for pd symbols, although I'm not sure whether backslash or brackets can appear as shift bytes for any characters: that could certainly cause problems. As an experiment, you could try calling the following on Pd startup: #include setlocale(LC_ALL,""); /*-- set locale from environment --*/ setlocale(LC_NUMERIC,"C"); /*-- ... but leave floats alone! --*/ ... and see what breaks (or doesn't) ;-) Alternatively, you can achieve pretty much the same effect with the "locale" external in userspace (see attached "uselocale.pd"). Of course, to test UTF-8 you should have your environment variables set accordingly (in particular LC_CTYPE, potentially via LANG): bash$ export LC_CTYPE=en_DK.UTF-8 bash$ pd uselocale.pd barf-both.pd ##-- latin-1 displays incorrectly bash$ export LC_CTYPE=en_DK.ISO-8859-1 bash$ pd uselocale.pd barf-both.pd ##-- all displays ok If it turns out to work well, we can of course make a trivial "dummy" external out of it for use with "-lib" ... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology barf-both.pd Description: application/puredata uselocale.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] locales for Pd WAS: japanese encoded chars in PD
moin Hans, moin all, On 2009-02-12 06:24:44, Hans-Christoph Steiner appears to have written: > On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote: >> for me, pd *does* display utf-8 >> strings correctly in message boxes (tested with umlauts äöü, as well as >> Greek πδ > > Hmm, I am not sure that UTF-8 really is well supported. Some chars get > thru, but many don't. Here's an example. I typed these chars in a > UTF-8 text editor as an png and a pd patch. Not quite the same. ... I'm not really sure what (if anything) we can conclude from this. Maybe the text editor is making UTF-8 out of the keyboard input? The Pd patch itself is most cetainly not UTF-8 encoded, which makes me suspect that either (a) Pd is dropping non-printing shift bytes (IOhannes has pointed out similar goofiness in t_binbuf, but I thought it was only restricted to NUL bytes) or (b) Tk isn't receiving UTF-8 character codes at all (whether this is Tk's fault or a system configuration issue is another question). At least the latter should be testable with a few quick wish hacks... >> Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an odd >> error message from Pd though: >> >> Pd: buffer space wasn't sufficient for long GUI string >> (repeated 3 times) > > I am guessing that the above error comes from the fact that Pd is > written for latin1 where every char is always 1 byte, so sending UTF-8 > could confuse things, since UTF-8 can have multi-byte chars. Kinda; but why is it only the presence of *latin-1* message boxes that cause complaints about "long GUI strings" (try deleting the utf-8 message box & reloading: the error disappears). I think an error is certainly justified in this case (we're feeding a latin-1 encoded message box to a Pd using a UTF-8 locale); I was just surprised by the form the error took ;-) >> I don't know for sure, but I suspect one problem might be in the >> interpretation of user input > > I don't know about the pd side, but Tcl/Tk is all UTF-8 natively, so > that is no problem. Hmm... not sure what you mean by "natively" here... I mean, Perl uses UTF-8 as its "native" string encoding, but you can still manipulate byte strings, read & write files etc in other encodings too. If we're talking about user input and the Pd GUI, I think the main issue is how keyboard input is captured by Tk and passed on to Pd. If the keyboard input is being grabbed by Tk bind()ing KeyPress events, then maybe we just need to edit that bind() call... looks like the KeyPress relevant "%"-substitutions are (from the Tk bind() manpage): %k - The keycode field from the event. Valid only for KeyPress and KeyRelease events. %A - Substitutes the UNICODE character corresponding to the event, or the empty string if the event does not correspond to a UNICODE character (e.g. the shift key was pressed). XmbLookupString (or XLookupString when input method support is turned off) does all the work of translating from the event to a UNICODE character. Valid only for KeyPress and KeyRelease events. %K - The keysym corresponding to the event, substituted as a textual string. Valid only for KeyPress and KeyRelease events. %N - The keysym corresponding to the event, substituted as a decimal number. Valid only for KeyPress and KeyRelease events. ... so if we're lucky, we can just replace "%k" with "%A" and all will be good... except for file I/O, which will likely still be done at a raw byte level. At this point, all "pure" latin-1 patches will proceed to break (maybe just display problems, maybe more serious). If we say we're going whole-hog utf-8, we can say that it's the user's problem to recode any such files (e.g. with iconv or recode; I'm happy to help out with a few scripts); otherwise we might want to do something paranoid and try to guess a patch's encoding when it's loaded. Or we use locale-dependent functions, but that makes sharing patches harder between people using different locales. Or we use the XML-style solution and just save the encoding to use in the patch header ;-) >> bash$ export LC_CTYPE=en_DK.UTF-8 >> bash$ pd uselocale.pd barf-both.pd ##-- latin-1 displays incorrectly >> >> bash$ export LC_CTYPE=en_DK.ISO-8859-1 >> bash$ pd uselocale.pd barf-both.pd ##-- all displays ok >> >> If it turns out to work well, we can of course make a trivial "dummy" >> external out of it for use with "-lib" ... > > Hmm, I tried this on Mac OS X and it didn't seem to make a difference. > Perhaps its a platform issue, though on this level, Mac OS X is very > much BSD, so I think it should work. The locale strategy also depends on what locales your system h
Re: [PD] string2any in arduino.pd is now broken
morning all, On 2009-02-12 10:42:10, Frank Barknecht appears to have written: > Hallo, > Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > >> So I have been happily using the string2any object in my arduino >> object and it works well. But it seems that something has changed, >> and it now causes a freak out on load: >> >> string2any_setup(): WARNING: names are in flux! >> string2any_setup(): Prefer [bytes2any] over [string2any]. >> bytes2any: pdstring version 0.09 by Bryan Jurish >> moocow/string2any: already loaded >> ... snip (repeat 1000 times) ... >> moocow/string2any: already loaded >> error: maximum object loading depth 1000 reached > > Isn't this the issue with hexloader reported some time ago? Does it > fail on vanilla or a pd-extended with no libs loaded as well? Hmm... I'm not familiar with the hexloader bug you mention. In trying to maintain maximal backwards-compatibility, I set up [pdstring] in single-object-external mode (which pd-extended uses) to install "any2string.pd_whatever" as a symlink to "any2bytes.pd_whatever". Additionally, any2bytes.c contains an "any2string_setup()" function as well as a runtime check to prevent multiple setup() calls. Is the problem due to the use of a symlink (e.g. does it persist if moocow/string2any.pd_linux is a copy of moocow/bytes2any.pd_linux?) Or is every solution ultimately relying on class_addcreator() doomed to failure? I can make [string2any] just an abstraction wrapping [bytes2any] as well; I just anticipated interference from old installations with that trick... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] locales for Pd WAS: japanese encoded chars in PD
moin all,
On 2009-02-13 03:14:20, Hans-Christoph Steiner appears to
have written:
> On Thu, 12 Feb 2009, Bryan Jurish wrote:
>> Are we certain that Tk is actually translating at all, and not just
>> using some 8-bit default like latin-1 when it finds non-UTF-8 input? I
>> ask because that's what Perl does by default, a behavior which continues
>> to give me headaches. In Perl, each string has its own internal "utf8"
>> flag which tells you whether Perl is currently thinking of that string
>> as a raw byte-string in some unknown encoding or as a "native" (utf8)
>> character string... I assume Tcl/Tk does something similar, but don't
>> know how to test for this property there.
>
> Here's the doc that I read on this topic, but it probably doesn't have
> the lvel of detail that you require:
>
> http://tcl.tk/man/tcl8.5/TclCmd/fconfigure.htm#M8
Had a look at that last night, but the 'fconfigure' command only applies
to Tcl streams (analagous to the PerlIO layer, which I abhore and try my
best to avoid, as it doesn't provide a sufficient level of control for
most of my purposes... fconfigure be ok for Pd-devel if we say we're
dealing exclusively with utf-8... but then again, I don't know if Tcl
streams ("channels") are used at all by the GUI... maybe on the socket
to the backend, but that's probably it; IMHO it's safer to explicitly
generate byte strings in a known encoding and just pass those around).
Also useful is the 'encoding' command family ('encoding convertfrom',
'encoding convertto', 'encoding names', 'encoding system'). Tried this
with some expicit escapes as well as a tester widget from
http://en.wikibooks.org/wiki/Tcl_Programming/Internationalization, and I
get decent display (Japanese still doesn't display with any Tk fonts I
tried, but I think that's just a font problem). Also tested the bind
substitutions with a dummy "puts" script, and managed to get real utf-8
sent out over the stdout channel for keyboard input. Still not 100%
sure how well it's working, since my keyboard only produces latin-1
symbols (maybe I'll hack my xmodmap for some real testing ;-)
Unfortunately, I still haven't found a way to get Tcl to tell me what
encoding (if any) it thinks a given string is using, analagous to the
Perl predicate "utf8::is_utf8($string)". Maybe Tcl doesn't track this
information on a per-string level at all, but assumes [encoding system]
for all strings? That seems pretty inflexible to me, but after another
look at http://www.tcl.tk/man/tcl8.5/TclCmd/encoding.htm , it does
indeed seem to be the case. So I guess the only safe way to handle
things is (as you suggest) to select an internal encoding (e.g. UTF-8)
and enforce its use with {encoding system "utf-8"}, and possibly
{fconfigure $ch -encoding "utf-8"} for whatever channels we want. The
fconfigure manpage says the default channel encoding is [encoding
system]; but I suspect that perhaps it's really the value of [encoding
system] at the time of the channel's opening which has an effect, so we
either have to make some accommodations for the standard channels
(stdin,stdout,stderr), or just leave that up to Tcl (which probably
defaults to the current locale's LC_CTYPE, but I haven't tested that
yet)...
> As for Tk hacking for Pd, a big part of the pd-devel effort is to make
> the Tk GUI code readable, and even extendable! Feel free to hit me with
> questions, either here, or I am in #dataflow quite a bit these days.
Groovy. I don't think I'll make the devel meeting today, but it's
beginning to look as if I've got a bit of a bug in my bonnet about this ;-)
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] locales for Pd WAS: japanese encoded chars in PD
morning all, On 2009-02-12 20:22:22, Hans-Christoph Steiner appears to have written: >> On 2009-02-12 06:24:44, Hans-Christoph Steiner appears to >> have written: >>> On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote: >>>> for me, pd *does* display utf-8 >>>> strings correctly in message boxes (tested with umlauts äöü, as well as >>>> Greek πδ >>> >>> Hmm, I am not sure that UTF-8 really is well supported. Some chars get >>> thru, but many don't. Here's an example. I typed these chars in a >>> UTF-8 text editor as an png and a pd patch. Not quite the same. >> >> ... I'm not really sure what (if anything) we can conclude from this. >> Maybe the text editor is making UTF-8 out of the keyboard input? The Pd >> patch itself is most cetainly not UTF-8 encoded, which makes me suspect >> that either (a) Pd is dropping non-printing shift bytes (IOhannes has >> pointed out similar goofiness in t_binbuf, but I thought it was only >> restricted to NUL bytes) or (b) Tk isn't receiving UTF-8 character codes >> at all (whether this is Tk's fault or a system configuration issue is >> another question). At least the latter should be testable with a few >> quick wish hacks... > > Pd does seem to measure the bytes of the string, measuring the UTF-8 > shift bytes as chars. For exmaple, in barf-both.pd, the message box of > the utf-8 example is much longer than the text inside, while with the > latin1, it is the correct size. yup. > I don't know if you have followed Pd-devel 0.41.4 at all, but I have > gotten to the point where the GUI is 100% Tcl/Tk so playing with this > stuff should be a lot easier. Check out the branch, if you would like > to try things. soon. >>>> Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an odd >>>> error message from Pd though: >>>> >>>> Pd: buffer space wasn't sufficient for long GUI string >>>> (repeated 3 times) >>> >>> I am guessing that the above error comes from the fact that Pd is >>> written for latin1 where every char is always 1 byte, so sending UTF-8 >>> could confuse things, since UTF-8 can have multi-byte chars. >> >> Kinda; but why is it only the presence of *latin-1* message boxes that >> cause complaints about "long GUI strings" (try deleting the utf-8 >> message box & reloading: the error disappears). I think an error is >> certainly justified in this case (we're feeding a latin-1 encoded >> message box to a Pd using a UTF-8 locale); I was just surprised by the >> form the error took ;-) > > I think that Tcl/Tk tries to guess the locale of the data coming in from > the network socket, then translate it to UTF-8 and back. Some of the > weirdness we are seeing could be related to that. In Pd-devel, its much > clearer, so it would be straightforward to play with this encoding > translation stuff, and perhaps turn it off. Ideally we could have UTF-8 > coming from Pd so that Tk doesn't need to do any translation. That > could speed up things like array/graph redrawing. Are we certain that Tk is actually translating at all, and not just using some 8-bit default like latin-1 when it finds non-UTF-8 input? I ask because that's what Perl does by default, a behavior which continues to give me headaches. In Perl, each string has its own internal "utf8" flag which tells you whether Perl is currently thinking of that string as a raw byte-string in some unknown encoding or as a "native" (utf8) character string... I assume Tcl/Tk does something similar, but don't know how to test for this property there. >>>> I don't know for sure, but I suspect one problem might be in the >>>> interpretation of user input >>> >>> I don't know about the pd side, but Tcl/Tk is all UTF-8 natively, so >>> that is no problem. >> >> Hmm... not sure what you mean by "natively" here... I mean, Perl uses >> UTF-8 as its "native" string encoding, but you can still manipulate byte >> strings, read & write files etc in other encodings too. > > Yes, same idea. Internally, Tcl/Tk is using UTF-8, but it can freely > translate between other encodings. see above. >> If we're >> talking about user input and the Pd GUI, I think the main issue is how >> keyboard input is captured by Tk and passed on to Pd. If the keyboard >> input is being grabbed by Tk bind()ing KeyPress events, then maybe we >> just need to edit that bind() call... looks like the KeyPress relevant >> "%"-substitutions
[PD] UTF-8 for pd-devel WAS: locales for Pd WAS: japanese encoded chars in PD
morning Hans, morning list,
So I've tried to get the pd-devel 0.41.4 branch to use UTF-8 across the
board. The TK side was easy (as Hans predicted); really just a call to
{fconfigure} in ::pd_connect::configure_socket. I also set the output
encoding to UTF-8 on Tk's stdout and stderr, for debugging purposes;
it's probably wisest to leave those encodings at the default (user's
current locale LC_CTYPE) for a release-like version.
The C side is much hairier. I think I've got things basically working
(at least for message boxes and comments), but it has so far required
changes in:
FILE: g_editor.c
+ changed handling of events as passed to the C side to generate
UTF-8 symbol-strings rather than single-byte stringlets.
+ currently use sprintf("%C") to get the UTF-8 string for the codepoint
passed from Tk; a safer (and not too hard) way would be to pass the
actual UTF-8 string from Tk and just copy that: this would avoid the
m_pd.c hacks forcing LC_CTYPE=en_US.UTF-8 (see below). Another option
would be actually just writing (or borrowing) the code to generate UTF-8
strings from Unicode codepoints. It's pretty simple stuff; I've still
got the guts of it somewhere (only written for latin-1 so far, but the
principle is the same for all codepoints).
FILE: m_pd.c
+ added calls to setlocale() to set LC_CTYPE to en_US.UTF-8; this is an
ugly stinky nasty hack to get sprintf("%C") to output a UTF-8 encoded
string from an unicode codepoint int, as called by canvas_key() in
g_editor.c
FILE: g_rtext.c
+ added an 'else if' clause in rtext_key() to handle unicode codepoints
as values of the 'keynum' parameter. should also be safe for any 8-bit
fixed-width encoding.
FILE: pd.tk
+ set system encoding, also output encoding for stdout, stderr to UTF-8
Attached is a screenshot and a test patch. UTF-8 input from the
keyboard works with the test patch, and gets carried through properly to
the .pd file (and back on load).
I'd like to get symbol atoms working too (haven't tried yet), but there
are still some nasty buglets with comments and message boxes, mostly
that editing any multibyte characters is very tricky: looks like the Tk
point (cursor) and selection are expressed in characters, and Pd's C
side is still thinking in bytes, though I'm totally ignorant of where or
how that can be changed. A non-critical buglet with the same cause
(probably) is that the C side is computing the required width for
message boxes based on byte lengths, not character lengths, so message
boxes containing multibyte characters look too wide. I could live with
that, but the editing thing is a real pain...
I've attached a diff of my changes against branches/pd-devel/0.41.4/src
(please excuse commented-out debugging code), in case anyone wants to
try this stuff out. Since it's not working, I'm reluctant to check
anything into the pd-devel/0.41.4 branch yet -- should I branch again
for a work in progress, or do we just pass diffs around for now?
marmosets,
Bryan
On 2009-02-12 06:24:44, Hans-Christoph Steiner appears to
have written:
> On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote:
>> On 2009-02-11 03:04:34, Hans-Christoph Steiner appears to
>>> This is something that I would really like to have working properly in
>>> Pd-devel. Tcl/Tk is natively UTF-8, so it seems that we should support
>>> UTF-8 in Pd. Anyone feel like trying to fix it?
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
test-utf8.pd
Description: application/puredata
<>Index: m_pd.c
===
--- m_pd.c (revision 10779)
+++ m_pd.c (working copy)
@@ -295,6 +295,18 @@
void glob_init(void);
void garray_init(void);
+/*--BEGIN moo--*/
+#include
+void locale_init(void) {
+ setlocale(LC_ALL,"");
+ setlocale(LC_NUMERIC,"C");
+ setlocale(LC_CTYPE,"en_US.UTF-8");
+ /*
+ printf("moo: locale=%s\n", setlocale(LC_ALL,NULL));
+ printf("moo: LC_CTYPE=%s\n", setlocale(LC_CTYPE,NULL));
+ */
+}
+
void pd_init(void)
{
mess_init();
@@ -302,5 +314,5 @@
conf_init();
glob_init();
garray_init();
+locale_init(); /*-- moo --*/
}
-
Index: g_editor.c
===
--- g_editor.c (revision 10779)
+++ g_editor.c (working copy)
@@ -1468,9 +1468,16 @@
gotkeysym = av[1].a_w.w_symbol;
else if (av[1].a_type == A_FLOAT)
{
+ /*-- moo: old
char buf[3];
-sprintf(buf, "%c", (int)(av[1].a_w.w_float));
+ sprintf(buf, "%c", (int)(av[1].a_w.w_float));
gotkeysym = gensym(buf);
+ --*/
+char buf[8];
+ sprintf(buf, "%C&quo
Re: [PD] UTF-8 for pd-devel WAS: locales for Pd WAS: japanese encoded chars in PD
moin Hans, moin list, On 2009-02-19 18:43:49, Hans-Christoph Steiner appears to have written: > > This is good news! While the C changes aren't dead simple, they are not > bad. I think they could be slightly simplified. One thing that would > make it much easier to read the diff is if you create it without > whitespace changes. So like this: > > svn diff -x -w oops, sorry... duly noted for future diffs ... I also set my emacs' tcl-indent-width to 8 ... sorry sorry sorry ... > As for the Tcl changes, I think we can include those now in Pd-devel, as > long they can work ok with unchanged C code. Done. > Then once the new Tcl GUI > is included we can refactor the C side of things with things like this. > One other thing, it seems that the ASCII char are handled differently > than the UTF-8 chars in g_rtext.c, I think you could use instead > wcswidth(), mbstowcs() or other UTF-8 functions as described in the > UTF-8 FAQ > > http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod Certainly, but (A) we already have the UTF-8 byte string in keysym, and we need to append that whole string to the buffer anyways, and (B) using wcswidth() & co requires forcing the locale to have a UTF-8 LC_CTYPE. I know I did this in m_pd.c, but I think that was a HACK and that using locale functions here is the Wrong Way To Do It, because it's dangerous, unportable, and slow (warning: rant follows): __dangerous__: setting the locale is global for all threads of a process; in forcing the locale, we could conceivably mess with desired behavior elsewhere (e.g. in externals). __unportable__: we don't even know if all users' machines *have* a UTF-8 locale installed, and even if they do, we don't know what it's called. If we don't force the encoding, we're stuck with either "C" (e.g. ASCII; what we've got now in Pd-vanilla), or whatever the user is currently employing (after setlocale(LC_ALL,"")), which makes patches' appearance dependent on the user's encoding (e.g. what we've got now in Pd-vanilla), and doesn't even work in the case of variable-length encodings such as UTF-8. __slow__: many locale-based conversion functions are known to be pretty darned slow. if we assume we're always dealing with (valid) UTF-8, we can speed things up considerably. going straight to wchar_t is another option, but would require many more changes on the C side, likely break the C API, and wouldn't solve the locale-dependency of patches' appearances, which I think is a really good argument for UTF-8. (rant finished now, sorry) That said, a faster implementation would probably result from mixing (something like) wcswidth() and strncpy(...,keysym). Functions like wcswidth() and mbstowcs() are pretty easy to cook up if we assume wchar_t is UCS-4 and the multibyte encoding is UTF-8. There are a number of libraries and code snippets floating about in the net making just such assumptions. In this context: are there any licensing restrictions on code included in pd-devel? So far, I've found one useful-looking (.c,.h) pair in the public domain, as well as some LGPL code from gnulib, which could be linked in statically. There's also code from the Unicode Consortium themselves, but it's pretty monstrous (read "pedantic") and limited to string-to-string conversions. marmosets, Bryan > On Feb 17, 2009, at 5:53 PM, Bryan Jurish wrote: > >> So I've tried to get the pd-devel 0.41.4 branch to use UTF-8 across the >> board. The TK side was easy (as Hans predicted); [snip] >> The C side is much hairier. [snip] -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] UTF-8 for pd-devel WAS: locales for Pd WAS: japanese encoded chars in PD
moin all, On 2009-02-20 06:20:18, Hans-Christoph Steiner appears to have written: > On Feb 19, 2009, at 4:13 PM, Bryan Jurish wrote: >> moin Hans, moin list, On 2009-02-19 18:43:49, Hans-Christoph >> Steiner appears to have written: >>> One other thing, it seems that the ASCII char are handled >>> differently than the UTF-8 chars in g_rtext.c, I think you could >>> use instead wcswidth(), mbstowcs() or other UTF-8 functions as >>> described in the UTF-8 FAQ >>> >>> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod >> >> Certainly, but (A) we already have the UTF-8 byte string in keysym, >> and we need to append that whole string to the buffer anyways, and >> (B) using wcswidth() & co requires forcing the locale to have a >> UTF-8 LC_CTYPE. I know I did this in m_pd.c, but I think that was >> a HACK and that using locale functions here is the Wrong Way To Do >> It, because it's dangerous, unportable, and slow (warning: rant >> follows): >> >> __dangerous__: setting the locale is global for all threads of a >> process; in forcing the locale, we could conceivably mess with >> desired behavior elsewhere (e.g. in externals). >> >> __unportable__: we don't even know if all users' machines *have* a >> UTF-8 locale installed, and even if they do, we don't know what >> it's called. If we don't force the encoding, we're stuck with >> either "C" (e.g. ASCII; what we've got now in Pd-vanilla), or >> whatever the user is currently employing (after >> setlocale(LC_ALL,"")), which makes patches' appearance dependent on >> the user's encoding (e.g. what we've got now in Pd-vanilla), and >> doesn't even work in the case of variable-length encodings such as >> UTF-8. >> >> __slow__: many locale-based conversion functions are known to be >> pretty darned slow. if we assume we're always dealing with (valid) >> UTF-8, we can speed things up considerably. going straight to >> wchar_t is another option, but would require many more changes on >> the C side, likely break the C API, and wouldn't solve the >> locale-dependency of patches' appearances, which I think is a >> really good argument for UTF-8. > > Isn't it pretty safe to assume these days that UTF-8 is supported? Yes, but under what name? Also, I believe the relevant locale variable (LC_CTYPE) requires a language component prior to the charmap, and we cannot guarantee that e.g. "en_US" is installed everywhere. The only locale guaranteed to be installed everywhere is "C", and that determines language and charmap simultaneously. Also, the "dangerous" property is impossible to get around, unless maybe we treat the locale like a stack and only force LC_CTYPE="(whatever).UTF-8" in code where we know we want/need UTF-8. I suspect this might slow things down enormously (although I haven't tested exactly what kind of overhead is involved). Adding threads to the picture means that we would have to add locking on LC_CTYPE (or similar) and that would only work if hypothetical locale-sensitive externals respected the same locks. All in all more trouble than it's worth, IM(ns)HO. > One thing I just found out is that Windows uses a 2-byte char > natively (UCS-2?), Probably. > I think Mac OS X uses UTF-8 natively. ... but not for wchar_t (which would be superfluous if sizeof(wchar_t)==1) ! > I think that most Linux tools should work with UTF-8 too, especially since it > can work as ASCII. Yes, but "working with" UTF-8 is by no means synonymous with supporting a particular (and known) value of LC_CTYPE which happens to use UTF-8 as its charmap. Most text-processing tools "work with" UTF-8 because they can get away with just churning bytes -- this is not the case for Pd (which counts characters to move the selection, edit buffers, determine box widths, and maybe more)... > So you think we can have full UTF-8 support without using those > functions? In a word: yes. Specifically, I think we can have full UTF-8 support without using those functions *as provided by the C99 locale API*. That amounts to rolling our own versions of the same and/or similar functionality. In particular, the (utf8.c,utf8.h) code by Jeff Bezanson (see http://www.cprogramming.com/tutorial/unicode.html) has some attractive utilities for wrapping typical string-processing code (in particular, u8_inc() and u8_dec() for adapting old byte-string processing code using i++ and i--, respectively), in addition to wrappers for the usual locale-style functionality: wcswidth() --> (trivial) (I've written the code) mbstowcs() --> u8_toucs()
Re: [PD] httpget: fun with tcpclient and pdstring
adding this to the GSoC ideas wiki... actually, there's some disabled table-storage code in [pdstring] as well; perhaps I'll get a chance to polish that up sometime soon.. marmosets, Bryan On 2009-03-04 19:01:31, Hans-Christoph Steiner appears to have written: > It seems that we should have a string.h for tables then. That would > be a good starting point, just make a library that is just Pd > interpretations of all the string.h strcpy, etc. functions, but have > them operate on arrays and maybe lists of floats too. > > There could also be a totally Pd-ish string library too. -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PdCon09: TeX paper templates
On 2009-03-12 14:01:24, IOhannes m zmoelnig appears to have written: > i just cannot write a paper in an office app. amen! -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] does anyone know of a good Eq I can use?
moin babysco, if you're on linux, you could use the LADSPA plugin 'Multiband EQ (1197/mbeq)'. Check if it's installed with: $ listplugins | grep mbeq Instantiate it in Pd with [plugin~ mbeq]. Send it 'control #N VAL' messages, where N is an integer between 1 and 16 (inclusive), and VAL is a dB value between -70 and 30 (inclusive) to change gain on each of the 16 bands. I've got a GUI for this hanging around if you're interested, but it probably requires a whole mess of my other abstractions and maybe even hacked externals. Still, you (or anyone elese) are welcome to it. You could also try generating a GUI yourself with my Pd::Patch perl modules, which come with a ladspa-plugin-wrapper-generator, but then you'd probably need to write your own abstraction template ;-) marmosets, Bryan On 2009-03-20 03:39:40, babsyco babsyco appears to have written: > Hi guys, > > I was just wondering if anyone knows where I can find a decent 8-band > (or greater) Eq patch? I don't need anything too fancy-I tried to make > one myself, but I'm still figuring out how the lop~ and hip~ objects > work and I'm in kind of a hurry. > > Thanks-enjoying all your emails very much. > > babsyco. > > > Explore the new Windows Live. Looking for a place to manage all your > online stuff? <http://www.microsoft.com/australia/windows/windowslive/> > > > > > _______ > Pd-dev mailing list > pd-...@iem.at > http://lists.puredata.info/listinfo/pd-dev -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] My first external: [fsm] finite state machine for pd
moin lsw, pretty cool, especially since it has next to no dependencies (unlike [gfsm], which needs glib and of course libgfsm ;-) Any chance of adding some AT&T-style I/O routines for compatibility? That way, users could easily switch back and forth between [gfsm_automaton] and [fsm] representations by bouncing the data over the filesystem (ugly but portable), so you could get visualization with dot, regex compilation, markov chain generation, weighted transitions, etc. etc. ... marmosets, Bryan On 2009-04-15 23:59:32, lsw appears to have written: > Dear list, > > i have been absent from pd-list for a few years, but i'd like to change > that. :) > > During the last days i wrote my first external: fsm - finite state > machine for pd > I wrote this with algorithmic sequencing and sequence recognition in mind. > You can find builds for win32, osx and linx, as well as the sources and > help-patch with > examples at http://floppy35.de/pd/ > I didn't test the windows and linux builds (but osx-version seems to > work fine), > so please tell me, if it works or if it destroys your machine and > deletes your > mp3-collection. ;) > > Unfortunately i saw a bit late that moocow had a similar idea earlier... > however, my > external seems to be a bit different (low-level approach), so it might > be still useful > for some of you. It's written in plain C and consists of one single > c-file, so it should > be easy to port and compile for different platforms. > > Feedback is appreciated. > > All the best, > lsw~ -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] MinGW/Windows work session - tomorrow, Tuesday 5/18
morning all, as previously mentioned off-list, I'm likely to be a bit late in joining the misery, so I've gone and prepared a whole lot of buffered misery for y'all to play with (if time and interest permit) before I join in ;-) Circa 20MB of the aforementioned misery is available in concentrated form for a limited time only at: http://odo.dwds.de/~moocow/moo.mingw-build.2009-05-17.tar.bz2 included are sources, patches, and scripts for building the following on mingw/msys: flite : svn export, with patch & build script zlib : sources & build script expat : also libiconv : also also gettext : from the mingw site, with extra hacks (as patch) pkg-config : binary only, due to circular dependencies with glib libglib-2.x : sources & build script ... I've now successfully built all of these on my test machine (after killing the §"§&%$"§ webcam daemon... grr...), and included in the archive are build scripts a la 'build-libs-on-mingw.sh' for all of the libs (the only difference being an optional argument to force building even if the test-file is present). There's also a './build-all-moo.sh' to build everything in the archive in (I think!) an acceptable order. feel free to commit any or all of this, with or without applied patches to the sources/ section and/or the main build-libs-on-mingw.sh script; otherwise I can do some or all of it when I show up (and reminisce about the bad old days of 2400 baud as I watch the IRC traffic crawl past during the commit ;-) enjoy (ha!) marmosets, Bryan On 2009-05-18 21:39:58, Hans-Christoph Steiner appears to have written: > > August has ported gavl and gmerlin-avdecoder to MinGW, and August and I > have been cranking on trying to get the whole slew of libs building for > MinGW, so now we have a good reason to put some time into the MinGW > setup for Pd builds. readanysf~ uses them and with them works really > well. Gem is also going this route. It would make life much easier if > the Windows builds did too. > > We are thinking it would be a lot more productive if we all work at the > same time on this stuff via IRC. Then we can ping each other with > questions, complain, swear at Windows, etc. You don't need to be a C > coder or an expert of any kind, just have an interest in getting things > building with MinGW. The more the merrier, join us in the sharing the > pain! :D > > tomorrow (May 19, 2009-05-19) on IRC in #dataflow: > irc://irc.freenode.net/dataflow > > * 9.00 Pacific Time > * 11.00 Central Time > * 12.00 Eastern Time/PET > * 15.00 BRST/Sao Paulo > * 17.00 GMT/Zulu > * 18.00 Central European CET > * 19.00 EET/Istanbul/Cairo > * 20.00 MSD - Moscow Daylight Time > * 23.00 IST/Chennai > * 1.00 CST/Taipei (2009-05-20) > > .hc -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] MinGW/Windows work session - tomorrow, Tuesday 5/18
moin all, On 2009-05-21 18:10:35, Hans-Christoph Steiner appears to have written: > > On May 21, 2009, at 11:53 AM, august wrote: > >>> >>> So of your list there, we still have to handle glib and pkg-config. As >>> for binaries, there currently isn't really a way to manage them. Right >>> now, the setup uses binaries from the MinGW and MSYS installers, then >>> everything else is checked into SVN 'sources' and built from source. In >>> order to make this setup reproduceable, it needs to be simple. >>> >>> I think August got pkg-config going, was that a binary? >> >> >> yeah, the only way to go is with binaries due to a circular dependency >> with glib and pkg-config. after a brief look at glib's configure.ac, it looks to me like the glib -> pkg-config "dependency" isn't really one, and could be fixed by some judicious use of 'dnl' (m4 comment-ization) in glib/configure.ac. > Which binary did you use? Is there an 'official' MinGW one? I second the question: august? for my own part, I didn't find a pkg-config binary from either mingw or gnuwin, so i used the binaries referenced on gtk.org: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config-0.23-2.zip which worked to build glib, but after 'svn up'-ing pure-data/sources, a whole bunch of libs have been complaining, and I'm getting pkg-config crashes during build-libs-on-mingw.sh (i can attach a log, but it's huge and i haven't really identified the problem yet). so i think a better way to go would be: + comment out the AC_PROG(pkg-config) in glib/configure.ac (or configure.in, I forget which convention glib uses) + tweak the libpcre clauses so that they don't call pkg-config (afaict, the GRegex/PCRE stuff is the only place glib actually calls pkg-config), + re-generate the glib autotools stuff (e.g. autoreconf) + use the --with-local-pcre or whatever option to glib ./configure and it ought to build ... no time for this atm, especially since these other libs are giving me grief and annoying segfault popups ... grr Strangely, http://pkgconfig.freedesktop.org/wiki/ (the official pkg-config home) reports: "A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly" huh... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-flite text-to-speech offline ?
moin Tim, moin all, sorry for the belated reply -- just got back from vacation. it turns out that there was a typo in the index file (fixed now; thanks for the report!): the pd-flite source distribution lives at: http://www.ling.uni-potsdam.de/~moocow/projects/pd/pd-flite-0.02-2.tar.gz ... or of course in SVN. marmosets, Bryan On 2009-08-21 16:36:31, tim vets appears to have written: > Hi all, > I wanted to try out this external from Bryan Jurish but it seems to be > unavailable. > http://www.ling.uni-potsdam.de/~moocow/projects/pd/pd-flite-0.02-2.tar.gz > is a dead link. > anywhere else could I find this ? > Bryan, are you here ? :) > thanks! > Tim > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-flite text-to-speech offline ?
argh argh argh ... mistyped again (sorry). the url should be (really, I mean it this time): http://www.ling.uni-potsdam.de/~moocow/projects/pd/pdflite-0.02-2.tar.gz marmosets, Bryan On 2009-08-24 21:23:44, Bryan Jurish appears to have written: > http://www.ling.uni-potsdam.de/~moocow/projects/pd/pd-flite-0.02-2.tar.gz -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] message box issue with blank spaces
moin Matteo, moin list, afaik, the issue you're observing is due to the message box, which uses t_binbuf internally to (re-)parse messages into pd atoms. you are correct that symbols can easily contain spaces (and pretty much anything else except for ASCII NUL): the problem is getting the funny bytes in & back out again... anyone else should feel free to correct me on this if I've got it wrong, of course... marmosets, Bryan On 2009-12-08 20:43:37, Matteo Sisti Sette appears to have written: > Hi, > > As far as I know, some representation of the space character does exist > in PD which can be contained in symbols. > The "proof" is that if I bang an [openpanel] and I browse to a file > whose path contains spaces, I can send the output to a symbol atom, > print it, use [label $1( to send it to a canvas etc and it doesn't get > truncated. I can store it in a [symbol] and use later without issue. So > that kind of symbol definitely exists, no matter how it is internally > represented. > > But if I send such a symbol (containing blank spaces, e.g. the output of > an openpanel) to the following chain: > > ... > | > [list prepend set] > | > [list trim] > | > [ ( > > > then the symbol IS truncated at the first space. > > That is, the [set( message to a messagebox doesn't seem to handle > correctly symbols containing a blank space. > > Before I report it to the bugtracker, am I missing something? > > P.S. the same results are obtained with > > [set $1( > | > [ ( > > but since it involves two message boxes i thought it could be more > confusing. > -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] message box issue with blank spaces
moin moin, On 2009-12-09 10:37:10, ypatios appears to have written: > Hello > > Very interesting observation. > i guess it has to do with the openpanel and savepanel objects. It's > probably a special kind of symbol that represents the possible spaces > (which in reality are no spaces anyway..) for compatibility with the OS. Not really -- there's nothing "special" about the *symbols* at all. Frank is right: the difficulty is in (re-)parsing them, which needs to happen when loading a patch, which means "funny" characters like spaces would need to be escaped when saving a patch, but pd lacks an escaping mechanism (e.g. in binbuf_text(), binbuf_add(), etc.). > Obviously you can't create such a message within pd. Unfortunately .. It's certainly not comfortable to create such symbols, but it is possible: you can use [list2symbol] from zexy to create symbols with spaces quite easily. Even in vanilla pd, you can do: [32( | [makefilename foo%cbar] | [symbol] | [print] ... which will create & print a single symbol "foo bar" (pipe it to [list length] if you don't believe me ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] makefilename inconsistency (or not?)
afaik, matteo is right:
sprintf(&s, "%.0s", "whatever")
outputs a null-length string to &s; i.e. afterwards
strcmp(s,{'\0'})==0
marmosets,
Bryan
On 2009-12-11 06:13:20, Hans-Christoph Steiner appears
to have written:
> On Dec 9, 2009, at 12:41 PM, Matteo Sisti Sette wrote:
>> Hans-Christoph Steiner escribió:
>>> What does printf do? It probably should mimic that behavior.
>>
>> I think it should mimic sprintf's behaviour to be precise.
...
>> according to the definition
>> it should just output a 0-length string.
>
> Just write a tiny C program to test what sprintf() actually does.
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdstring?
morning all, (almost missed this one; sorry)... this sounds very odd: I thought I had eliminated all black magic (e.g. multi-object library, class_addcreator(), etc.) from the pdstring externals during the bytes|wchars re-factorization a while back... urgh... might have to do with a static global flag i used as a workaround... no time to dig any deeper now, but i'll put it on the todo list... marmosets, Bryan On 2010-03-06 22:28:42, Hans-Christoph Steiner appears to have written: > > For some reason, they don't work like that. YOu need to: > > [import moocow] > > [any2bytes] or [bytes2any] > > .hc > > On Mar 6, 2010, at 10:17 AM, Martin Peach wrote: > >> They might work as: >> [moocow/any2bytes], [moocow/bytes2any], [list prepend set]. >> >> Martin >> >> Chipp Spam wrote: >>> Thanks for the examples with httpget ! >>> Had a problem running the example: any2bytes >>> ... couldn't create >>> bytes2any >>> ... couldn't create >>> prepend set >>> ... couldn't create >>> (Running latest version pd-extended on OS X). >>> Thanks >>> ~Chipp >>> On Mon, Mar 1, 2010 at 5:13 PM, >> <mailto:martin.pe...@sympatico.ca>> wrote: >>>And here's a version that gets the latest solar wind speed from the >>>ACE satellite... >>>Martin >>>hc wrote: >>> > >>> > Ah, right, here's an updated version, that will also disconnect if >>> > there's no response within 5000ms. >>> > >>> > .hc -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] linux multi-output soundcard
moin Marco,
in my desktop i've got an m-audio delta 1010 lt (used from e-bay), which
worked "out of the box" (8 unbalanced analalog i/o and midi from a "cat
o' 9 tails" which plugs directly into the card). its big brother (delta
1010, no "lt" suffix) has a nice breakout box (balanced) and uses the
same chipset ("envy24", alsa module snd-ice1712). iirc, the terratec
phase88 uses the same chipset with an unbalanced breakout box.
latency was ok out of the box (don't remember the numbers right now,
sorry), but i had to do some os-level tweaking to get things working to
my satisfaction (realtime kernel, irq priorities, pci settings, etc -
all scripted now and available on request). also, i had to comment out
a few lines in the envy24control sources (dedicated mixer gui for the
card) in order to stop my console from filling up with annoying warnings
-- really nothing more than an annoyance; i can send you a patch if you
have the same problem... if you can afford one, the rme cards are likely
to be much better, but my budget didn't stretch quite that far ;-)
marmosets,
Bryan
On 2010-04-12 14:11:41, Marco Donnarumma appears to
have written:
> Hi all,
> I know it's OT, but I would like to get an advice from Linux Pd users.
> I'm about to buy a soundcard with up to 8 analog I/O for max
> 500euro/pounds and want it to be compatible with Linux (I mean, I would
> like something working ""out-of-the-box"").
> I've been advised about the Terratec Phase 88 Rack..
> Any other suggestion?
--
Bryan Jurish "There is *always* one more bug."
jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard encoding of pd files in each system?
moin again, On 2011-01-30 17:07:44, Mathieu Bouchard appears to have written: > On Sat, 29 Jan 2011, Bryan Jurish wrote: >> In this scenario, we're blatantly re-casting the array's (t_float*) >> into a (char*) and reading/writing raw bytes. > > Ok, I thought you were going to write one codepoint per float and not do > any reinterpret_cast. > > I'd advise against relying on reinterpret_cast hacks like this, and > instead, add support for other number types in the t_array struct and > supporting functions. In that case it'd become significantly closer to > struct Grid, but without the support for multiple dimensions of indices. I agree that sounds like the best way within pd-vanilla as it appears currently to be constructed, but I'm not at all sure about how to go about it. And up until ca. 11:14 AM this morning, I had semi-major post-catholic guilt attacks every time I even thought about doing something involving a computer keyboard that didn't directly involve either my dissertation or my day job. Happily, the former is out of my hands now (fanfare, please :-) > This change could also prevent wasting half of the t_array memory when > storing floats on 64-bit computers, which is currently a good source of > ridicule. Agreed. >> Yes. See above re: >> char *s; >> garray_getfloatarray(a,size,(float **)&s); > > This is "deprecated" since 0.41, but really, this is a function call > that never ever worked properly in 64-bit mode. You need to use > garray_getfloatwords instead, which returns a t_word. Yes, I did see that the underlying data was stored as a t_word; I only briefly re-grepped the sources when composing my mail... I haven't really dedicated a whole lot of time to this attempt, as I think you can probably tell (bad hacker, no biscuit...) >> No. See above. Messing about with typecasts is very >> implementation-dependent, and afaik IEEE-754 doesn't define how its >> components are to be implemented, only the formal criteria an >> implementation must satisfy. > > If you (or pd) never actually read the contents as float values in your > use of reinterpret_cast to store, it doesn't matter, as you're doing > nothing with float* that may depend on the difference between, say, > float* and char*. True. But while I can guarantee this for "string-like" operations, I can't seem to finagle it for pd, which insists on treating arrays (at least those defined at the patch level) as t_float[]s (looks like the culprit here is garray_save() calling binbuf_addv() to buffer the array data, which assumedly gets dumped to the file at some point via binbuf_gettext(), which calls atom_string() which ends up dumping the float with the sprintf() "%g" format, i.e. truncating... but we all knew that already, right? > But you're not supposed to be using float* anymore, just t_word*, if you > want to continue with the reinterpret_cast hack. reinterpret_cast<> doesn't exist. there's only (char*)expr (cf. Kernighan & Ritchie, 1988) :-P sorry for being pedantic; you are of course correct that reinterpret_cast<> is the C++ equivalent for what I'm doing; I just think it's too much to type, which is yet another thing I dislike about C++ ... anyhoo, ok: I can (ab)use typecasts using (t_word*) instead of (t_float*). My original gripes (1C) and (1D) still hold: this breaks on save/load of patches, if "string" data is to be saved with its array. I can of course say "not my problem" and leave it at that, but there are still points (1A) and (1B). (1A) is really just a convenience issue (typecasting) -- if that was the only issue, I'd already have included the code in [pdstring]. (1B) is the string-length issue, and is much hairier. We can't get string length and array length always to jive, and if I add an extra object to store string length (and maybe other properties), then why don't I just dump the string data as a (char*) into that object, and leave g_array out of it entirely? Martin's patch does just this: he adds a (length,data) pair struct t_string and a t_string* to the t_word struct. I suppose I could divorce the underlying struct from t_word, wrap it into a new object, bind a symbol, etc etc I still think the idea of using arrays for strings is intriguing, not least for the sheer amount of abuse potential arising from combining text bytes and audio signals in the same arrays... so no, I guess I don't want to drop the g_array idea entirely (apologies for answering my own question)... >> deep hole very very quickly. fwiw, the raw text of the whole corpus I >> work with these days runs about 1G. A single file with all intermediate >> data can easily run over 400MB. I really wouldn&
Re: [PD] Abstractions x Externals
On 2011-02-16 14:02:52, Mathieu Bouchard appears to have written: > On Wed, 16 Feb 2011, Alexandre Porres wrote: > >> I was thinking of externals as anything that can be loaded as an >> object or library - like any non native/pd vanilla object - at startup. > > I'm sure, though, that you can find a word for it. Anyone got an idea > about how to name this ? > > "Non-internal classes", "classes outside of the main executable" ? "user-defined objects" ? "non-primitive objects"? ... or maybe "civilized objects" ? ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-09 13:08, Billy Stiltner wrote: > I have come to the conclusion that all audio is discrete. probably > everything measureable in the universe is discrete for that matter. sqrt(2) ? exp(1) ? pi ? ... certainly each of the "usual suspects" has a discrete specification, but I've always been a bit suspicious of the hardcore constructionist approach to irrational numbers (while at the same time finding it extremely attractive to my engineering/hacker instincts). ok, so these are probably not "measurable" in the sense you mean either, but they are *thinkable*, and that (I think) is the whole point (or as it were, the whole hypotenuse, curve, circle, etc) ;-) uncountably infinite marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-19 14:01, Simon Wise wrote: > That is which numbers are directly perceivable, without some more > abstract mathematical mapping to guide us? Zero ;-) > Certainly most people can look at four matches on a table and see that > there are four, without doing any counting at all. That's "four matches", not "the number four". If by "number" you mean the characteristic property of all sets of 4 elements, you're perceiving something (the matches) which has that property, but you can't directly perceive the property itself (i.e. its `intension'), because it's a function (in the mathematical sense) from all possible entities (let's ignore possible worlds for now) to a truth value indicating whether or not that entity is a set-of-four. This view is pretty unsatisfying for a number of reasons (for one thing, it doesn't work well for anything other than positive integers), but I hope it suffices to show that "the number four" can't be perceived directly. The same sort of argument goes for other "simple" qualities like volume, mass, density, color etc -- this stuff has had epistemologists tearing their hair out for centuries. There are 2 main camps, and I'm more or less solidly in the one that says "numbers exist" :-) > In some languages, where mathematics hasn't become part of the language, huh? do you happen to know of one specifically? > and the words for numbers are pre-mathematics, counting goes something > like "one, two, three, four, many" ... many one, many two, many three, many four, many many, ... many many one, many many two, many many three, many many four, ... LOTS [courtesy of Terry Pratchett] ;-) > so I guess that backs up the idea > that the first few integers are perceived directly, Again, I take issue with the details, but yes: there's a lot of empirical evidence that human cognitive/perceptual apparatus does some specialized handling for small sets, including counting. How we get those sets to be __sets__ (as opposed to arbitrarily co-occuring random perceptual data packets) is quite another matter, and im(ns)ho a much more interesting one. > but every other > number - counting numbers past that, zero, negative integers, the rest > of the rational numbers, the rest of the real numbers, the rest of the > complex numbers, ... and so forth are all just constructs in the > language of mathematics which all happen to have some quite useful > mappings to things we can observe around us. Most integers do not have > any more 'existence' (however that may be defined) than complex numbers. I'll agree that integers and complex numbers have the same sort and degree of existence, but I don't believe they're `constructs'. If forty-two trees fall in a forest and no one is around to count them, __forty-two__ trees have still fallen. marmosets, Bryan -- *** Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:jur...@bbaw.de *** ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-20 07:01, Chris McCormick wrote: > On Thu, May 19, 2011 at 05:12:09PM +0200, Bryan Jurish wrote: >> If forty-two trees fall in a forest and no one is around to count >> them, __forty-two__ trees have still fallen. ... > Of course, there is nothing to stop there being models of things that > don't exist in the real universe, but those models still exist in the > physical universe on the chemical and electrical substrate of > somebody's physical brain. Sorry, I don't buy that. My two main problems with that sort of hardcore empiricism are (in a nutshell) ego (aka "consciousness") and will. To paraphase the ol' p-ant hisownself, 'where does the "I think" come from which can be prepended to any proposition or perception I'm currently entertaining?' And if thoughts are just phsyical processes in brains and brains are just physical objects subject to physical laws, you run into determinism pretty darned fast, which is often taken to be a bit of a bummer. The really insidious problem (afaic, and the one that's most germane to the present (way way way off-topic by now) discussion) is that of inductive "knowledge", and I'm more or less professionally obliged to come down on the rationalist side of that one. > The physical painting is a zipfile containing a program that you run > on the chemical computer inside your head. ... but the __process__ that runs (whether on wetware, some massive parallel neural net, a suitably configured universal Turing machine, or whatever) is something distinct from and independent of the hardware it runs on, not to mention the location of that hardware, the time interval for which the process runs, and the physical laws of the universe in which it's running. The kind of existence and independence that process has is the same kind of existence and independence all formal objects have, imho. > but I don't think it's accurate to say without the computational > aparatus to perceive it that "42 trees are falling". I do :-) > Well, that's my current rather crap and innaccurate model of reality > anyway. It's crap but I think it's less wrong than yours, where > there is some nebulous flying spaghetti monster called "42 trees" > floating around outside of physical reality. ;) ... I think we're probably bound to to disagree on this, and that's fine by me, but just to be precise here: No, in my version there's an FSM called "42" floating around __independently__ of physical laws and processes. "Outside of" is locative, and I'm not talking about location (which I'm sure you know, I'm just trying to set the record straight here). And "outside of physical reality" is just polemics -- I'm saying not all that is real is (always) phyiscally realized. > Information, Matter, Energy - all just crude models for something we > probably can't ever truly know.* See above re: inductive knowledge ;-) > Also, physicists probably have much > better models. Knowing a few of them, I kind of doubt it. > http://mccormick.cx/news/entries/inherent-limitations-of-a-computational-model-of-reality That's a pretty twisted take on Gödel you've got there. By your logic (if I'm reading it right), there can be no such thing as a universal Turing machine *because* its ability to simulate itself prevents its very existence. But a universal Turing machine is really not all too hard to define (Turing, 1937): sure, we can't say whether or not it __terminates__ for itself, but that's a problem with *computability*, not with existence. We may at some point actually define a `perfect' computational model of reality, we just won't be able to prove it, since at that scale the map will have become indistinguishable from the territory. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-20 16:05, Simon Wise wrote:
> On 19/05/11 23:12, Bryan Jurish wrote:
>> On 2011-05-19 14:01, Simon Wise wrote:
>>> That is which numbers are directly perceivable, without some more
>>> abstract mathematical mapping to guide us?
>>
>> Zero ;-)
>
> My point is that it is not zero,
Sorry; that was intended as a joke -- a deliberate ambiguity between
zero ("the number zero"), zero ("the set with zero elements"), zero
("false"), and zero ("number of numbers which are 'directly
perceivable'"). It was late, I thought it was funny.
> Think about of what words like
> pair mean, is pair a number? is it a synonym for two? or is it a
> directly observable quality which is quite different from either a
> single thing or a few things?
"Pair" is a word of English, and a highly ambiguous one at that -- it
might be an ordered pair, an unordered pair, a pair of pants, a pair of
aces, 'a pair' (aka "couple"), or whatever. Yes, it's semantically and
pragmatically complex. The (abstract) number "2" plays a pretty heavy
role in all of its sense I can think of at the moment, though.
> Or thinking about the distinction between
> singular and plural forms of words.
What about them? They're usually related by quite simple and obvious
rules (e.g. 'add/delete an "s" at the end') except for a very few high
frequency lexemes. I agree it's interesting that number (the
grammatical feature 'number', i.e. singular/plural) is explicitly
encoded in the vast majority of human languages (even in English, which
encodes almost nothing else from the known spectrum of grammatical
features), and that it usually plays a role not just in morphology (word
formation) but also in syntax (sentence structure -- think subject-verb
agreement in English); but I'm not sure what you're getting at. Do you
mean the semantics usually associated with the feature (singleton vs.
non-singleton set) -- it's kinda cool that zero tends to get lumped in
with plurals in English (but usually not in German); not sure how other
languages go about that one (but I have solicited some references from
an acquaintance who worked on numbers and number features pretty
intensively a few years ago...)
>>> Certainly most people can look at four matches on a table and see that
>>> there are four, without doing any counting at all.
>>
>> That's "four matches", not "the number four". If by "number" you mean
>> the characteristic property of all sets of 4 elements, you're perceiving
>> something (the matches) which has that property, but you can't directly
>> perceive the property itself (i.e. its `intension'), because it's a
>
> this is the core of what I am saying - that three or four are something
> other than the result of counting the members of a set, and that for
> some unusual people quite surprisingly large numbers are perceived
> directly, independently of the process of counting. Occasionally the
> different status of these 'numbers' in language can be seen, they can be
> seen as words for some observable quality rather than as the first few
> of an infinite series of integers, used to describe a characteristic of
> sets of things.
I think I see what you're getting at, but I'm not sure where it's going.
I'll accept the "directly perceivable" term for current purposes, but
there's whole heckuvalot more going on in our heads (brains & associated
processes) when we look at and identify a small set of like items as a
set-of-N than I'm accustomed to calling "direct", and that's just the
stuff we know about...
>> function (in the mathematical sense) from all possible entities (let's
>> ignore possible worlds for now) to a truth value indicating whether or
>> not that entity is a set-of-four. This view is pretty unsatisfying for
>> a number of reasons (for one thing, it doesn't work well for anything
>> other than positive integers), but I hope it suffices to show that "the
>> number four" can't be perceived directly. The same sort of argument
>> goes for other "simple" qualities like volume, mass, density, color etc
>> -- this stuff has had epistemologists tearing their hair out for
>> centuries. There are 2 main camps, and I'm more or less solidly in the
>> one that says "numbers exist" :-)
>
> I am also in this camp, models do 'exist' in the way I use the word
> exist, but there are other ways to use this word, and so discussion gets
> tricky.
It's a unary predicate, i.e. an intransitive. It takes a
Re: [PD] CVs
moin Patrice, On 2011-05-23 05:09, Patrice Colet wrote: > We can imagine many different kinds of new animals, some also have been > modelized since a long time through sculptures, > we know that almost all those weird animals are not and have never been real. To pick a much-overused example, is the sentence "Pegasus is a flying horse" true or false? Or do we need to ditch the principle of bivalence? What the heck does "Pegasus" refer to anyways? Clearly, we can all parse the sentence and assign it some kind of semantic interpretation, and no one here is claiming to have actually perceived any airborne equines recently, but I think there's more going on here than can be adequately described by "so-and-so-many synapses in these-and-those brains dumped so-and-so-many neurotransmitters of such-and-such a chemical composition into their respective synaptic gaps in response to an influx of such-and-such a mean volume of sodium ions"... to put it bluntly, how `real' is fiction? Maybe that's what you were getting at in the first place; apologies if I'm beating a dead horse, airborne or otherwise ;-) marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
moin Andy,
On 2011-05-26 15:15, Andy Farnell wrote:
> Another great quote, I apologise for reading it again, I am always
> bringing this one out because it's elegant, is Quine
> who restates Shannon and Weaver in a way:
>
> "The notion of information is indeed clear enough... it is central
> to the theory of communication. It makes sense relative to one
> or another pre-assigned matrix of alternatives... You have to
> say in advance what features are going to count."
A good one indeed! Do you recall where it's from? Sounds to me like
he's talking about (something like) Shannon's "message" as the necessary
condition for information, but I'd have to dig into it some more to get
a clearer picture
> No pre-conception, no conception. Otherwise its novel, and a
> confusing jumble until some ordering, naming and searching
> of existing patterns has taken place. The next time, maybe
> then it's okay for those sensible impressions to become
> worthy of a symbol, like the number 42. In that case there
> are necessary conditions for the perception of 42 trees
> falling, other than the physical fact itself.
As far as language (or symbols) are concerned: yes, of course. But if
I'm reading it right, there's nothing which says that the "features"
(which may or may not "count" as information content) rely for their
ontological status only on their use (or non-use) in a Shannon-esque
"message" (although I admit that just that kind of assertion would be
consistent with Quine).
> On Fri, 20 May 2011 13:01:54 +0800
> Chris McCormick wrote:
>
>> chemicals and electricity inside the perceiver's physical head,
>> models another part of the universe - what it calls the "42 trees
>> falling".
To clarify (again): my emphasis was on the cardinal "42" (determiner of
the subject NP), not on the whole subject NP ("42 trees"), the
predicated state ("are falling"), or the non-constituent "trees are
falling". Further, I'm talking about the semantic content of the
cardinal we write "42", not about its syntactic or pragmatic properties.
In particular, I mean the sense of "42" as a natural number, i.e. the
same sense in which it is used in mathematical equations like "42=6*7".
I used the koan-esque natural language example of falling trees because
Chris was emphasizing the perception of physical phenomena, and it
seemed appropriate.
Maybe you're taking issue with the (essentially arbitrary) lumping
together of whatever physical processes we English speakers call "42
trees falling" into the constituents [42 trees] and [falling]. In
particular, you might well take issue with the [42 trees] part: are what
we call [42 trees] really in fact 42 distinct separate quasi-independent
objects in their own right (a la Aristotelian `substance'), or are they
just an arbitrary bundle of data/matter/processes which we happen to
call [tree] of which the number of instances for which the predicate
[falling] holds happens to be 42? If so, I think the objection is
entirely justified: I don't particularly care for the notion of
Aristotelian substance and I suspect there isn't anything physically
realized at all which is in fact a quasi-independent object in its own
right.
My point being (again) that the `42' part is independent of how we
happen to carve up physical reality / perceptual data / physical
processes into `objects', and also of how (or whether) our language
happens to divvy that up into nouns, verbs, adjectives, and what have
you (although I think many of the interesting abstracta tend to wind up
as `function words' -- `the', `is', `42', etc.). In this sense, if you
take our conventional semantics for [42], [tree], and [falling], even if
no one is around to construct or interpret the utterance, the associated
semantic proposition still holds. A less complicated example is the
equation: "42=6*7" holds whether or not there is anyone around to
evaluate it.
marmosets,
Bryan
--
***
Bryan Jurish
Deutsches Textarchiv
Berlin-Brandenburgische Akademie der Wissenschaften
Jägerstr. 22/23
10117 Berlin
Tel.: +49 (0)30 20370 539
E-Mail:jur...@bbaw.de
***
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] CVs
On 2011-05-26 14:58, Andy Farnell wrote: > Alan Watts, and to some extent Pierre Grimes analysing > Plato, gave me some good thoughts on this. > > If we weren't neural networks, prone to classification, > the question might be, are there different kinds of > intelligence? Or is what we do, (throwing boundaries > around things and concepts), intelligence by definition > only? I'm not at all sure what `intelligence' is, but I don't think that matters too much. The really tricky terms (at least for me) are things like "logical consistency", and of course the ubiquitous "truth" and "reference" (I suppose intelligence plays into it if you think that only intelligent beings can appreciate such things). Since we're trading snappy quotes, here's one: "... there is the question which is hardest of all and most perplexing, whether unity and being, as the Pythagoreans and Plato said, are not attributes of something else but the substance of existing things, or this is not the case, but the substratum is something else" - Aristotle, Metaphysics, Book III marmosets, Bryan -- *** Bryan Jurish Deutsches Textarchiv Berlin-Brandenburgische Akademie der Wissenschaften Jägerstr. 22/23 10117 Berlin Tel.: +49 (0)30 20370 539 E-Mail:jur...@bbaw.de *** ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
