Re: [PD] GEM: the sound is gone!!
On Tue, Nov 11, 2008 at 11:02 PM, Olivier Heinry wrote: > > > in the meanwhile, the laziest can use gems.movies~ from the pdmtl > abstractions > > tried it but i'm missing [phasorshot~] where can i download it? best ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [arduino] object & analog inputs
On Fri, 13 Feb 2009, glerm soares wrote: My doubt is: how to get a *totally* not flickering analog input with more than 64 steps? Even if you have only two steps, if the value is exactly on the limit, even the tiniest noise will make the input flip from 0 to 1 and back, endlessly. The solution is then to use some kind of modified [change] that uses a confidence interval. So when you output an y, you also need to set a pair of [moses] so that it can find numbers outside of the interval y-c < x < y+c, or equivalently, abs(x-y) < c, where c is the minimum amount of change that you want to hear about. If you are in a two-dimensional system, it's better to consider pairs of inputs together as being one thing, and so for inputs (x,y) and outputs (u,v), check for hypot(x-u,y-v) < c, or equivalently, (x-u)*(x-u) + (y-v)*(y-v) < c*c; that way, your system will be independent of the angle of change. [change] itself can be replaced by a very small abstraction, and those two modified versions that I suggest, are not much bigger than that. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
On Feb 13, 2009, at 12:00 PM, Georg Holzmann wrote: > Hallo! > >> I tried with >> >> pd -lib threadlib >> >> then >> >> threadlib vers.0.1, library for threaded patching and externals >> 2005, by Georg Holzmann mailto:g...@mur.at>> >> heavily based on pd_devel code by Tim Blechmann >> WARNING: this is very experimental and may crash your patches ! >> >> >> ok. >> >> >> but sndfiler still not working (same error >> /usr/lib/pd/extra/sndfiler.pd_ >> linux: /usr/lib/pd/extra/sndfiler.pd_linux: undefined symbol: >> fifo_init >> sndfiler >> ... couldn't create >> ) > > OK - so then there must be a problem during linking I guess ... I have > to look into it. > > >> I like to use your external because ogg files save lots of disk >> space, >> and it's easier to distribute patches with the samples attached... > > Yes I understand - but OTOH it is much harder do distribute a patch > which uses sndfiler, because everyone has to compile it ;) > (which can be quite tricky - especially for non-pd experts) > > >> Why can't pd-extended compile sndfiler ? > > I think I tried to add sndfiler to the pd-extended build system (which > should be quite straight forward) a year ago - but did not finish > because it has a dependecy to libsndfile - then pd-extended would need > to distribute this library as well ... > > But I agree that this is the way to go, then it should just work > > > LG > Georg libsndfile is installed on all the GNU/Linux and Mac OS X auto-build servers. I think it was installed on the Windows server too, but that's down due to a dead drive. (to return soon). .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ 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
On Feb 13, 2009, at 4:38 AM, Bryan Jurish wrote:
> 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 ;-)
Hey,
Its good to see someone iwlling to dive in deep. It'll be great to
have full UTF-8 support. Patko and I were looking into how to do it
on the C side, I think what you mentioned, using locale.h and
setlocale() should be enough. Maybe patko will chime in with some
details.
.hc
>
>
> marmosets,
> Bryan
>
> --
> Bryan Jurish "There is *always* one more
> bug."
> jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic
> Entomology
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [arduino] object & analog inputs
glerm soares wrote: >Hallo, > >I know this maybe too hardware concern issue, > >but since I am testing the new firmata with the [arduino] object, >and maybe this could interest other users, I think this could be a topic of >interest. > >My doubt is: how to get a *totally* not flickering analog input with more >than 64 steps? > >I always had the flickering problem even putting other pins to the >ground... > >generally I do > >[inlet] >| >[/8] >| >[int] >| >[change] >| >[outlet] > > > >I use 10k potentiometers, without resistors in the input... > >Does anyone get this input without any flickering? what's the secret? > > How much flickering are you talking about? You will always have settings with the least significant bit toggling no matter what your resolution. Short wires and good ground help, as well as clean connections. I found that a 0.1uF capacitor on the analog input can damp high frequency noise on the wire. Also 10k is at the upper limit for an analog input. Try 1k: a lower source impedance is quieter. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended on AMD 64
Ilias Anagnostopoulos wrote: > > I can host the deb on the OtherSide Ubuntu APT if this is fine with > you John. Sounds good! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [arduino] object & analog inputs
Hallo, I know this maybe too hardware concern issue, but since I am testing the new firmata with the [arduino] object, and maybe this could interest other users, I think this could be a topic of interest. My doubt is: how to get a *totally* not flickering analog input with more than 64 steps? I always had the flickering problem even putting other pins to the ground... generally I do [inlet] | [/8] | [int] | [change] | [outlet] I use 10k potentiometers, without resistors in the input... Does anyone get this input without any flickering? what's the secret? thanx glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended on AMD 64
As of today, I have regained access to an Ubuntu Hardy amd64 machine. I will download and test John Harrison's deb next week. I can host the deb on the OtherSide Ubuntu APT if this is fine with you John. If anybody else wants to test that deb, please let us know of your findings. -Ilias John Harrison wrote: > > > Ilias Anagnostopoulos wrote: >> >> >> Has anyone got a >> 64-bit binary ready that would be good enough as a 64-bit release >> (John Harisson was hosting one)? > I have a .deb and corresponding directions for building. The .deb was > built on a 64 bit Hardy machine. It worked for my purposes and I > didn't find anything broken but I can't say whether it is good enough > for release without further testing. Since I made that .deb I updated > my machine from 64 bit Hardy to 32 bit Intrepid so I'm not in a great > position to continue building and development of a 64 bit release, but > I am glad to help out if there is a place for me. > > .deb and instructions: > http://cratel.wichita.edu/cratel/cratel_Pd_extended_on_bit_64_Debian-based_OS > > (to be moved to the Pd wiki within the week) > > -John ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hallo, glerm soares hat gesagt: // glerm soares wrote: > this example is very rich and opened my mind... :) It's the same hack Miller mentioned some time ago to work around soundfiler's non-threadedness. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
2009/2/13 Frank Barknecht > Hallo, > > You can also use oggread~ with tabwrite~ to load ogg files into tables. > Use an upsampled subpatch to do this faster than the file's duration as > in the attached example. > wow thanks a lot Frank! this example is very rich and opened my mind... :) cheers! glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hallo, glerm soares hat gesagt: // glerm soares wrote: > Is there new versions of the [sndfiler] object or something similar (an > object similar to [soundfiler] that could read ogg sound files into tables ) > that comes with pd-extended compilation? Why pd-extended can't compile this? You can also use oggread~ with tabwrite~ to load ogg files into tables. Use an upsampled subpatch to do this faster than the file's duration as in the attached example. Ciao -- Frank #N canvas 334 258 840 468 10; #N canvas 285 182 836 478 loadfast 0; #X obj 114 152 switch~; #X obj 68 55 inlet; #X msg 114 123 1; #X obj 167 53 loadbang; #X text 63 34 filename; #X obj 91 216 oggread~; #X msg 91 191 open \$1 \, start; #X msg 165 216 0; #X obj 68 77 t b a b; #X obj 156 244 outlet; #X obj 250 52 inlet; #X text 290 94 <--- upsampled by factor of 128 \, then switched off ; #X obj 38 317 tabwrite~ \$0-samp-1; #X obj 180 317 tabwrite~ \$0-samp-2; #X msg 250 72 set 64 1 \$1 \, 0; #X msg 167 96 set 64 1 128 \, 0; #X text 315 129 Make sure to use blocksize 64 here \, as oggread doesn't like anything else!; #X connect 1 0 8 0; #X connect 2 0 0 0; #X connect 3 0 15 0; #X connect 5 0 12 0; #X connect 5 1 13 0; #X connect 5 3 7 0; #X connect 5 3 9 0; #X connect 6 0 5 0; #X connect 7 0 0 0; #X connect 8 0 12 0; #X connect 8 0 13 0; #X connect 8 1 6 0; #X connect 8 2 2 0; #X connect 10 0 14 0; #X connect 14 0 0 0; #X connect 15 0 0 0; #X restore 111 159 pd loadfast; #X obj 129 194 bng 15 250 50 0 empty empty done 17 7 1 10 -262144 -1 -1; #X obj 79 71 openpanel; #X msg 79 49 bang; #X obj 413 206 * 44100; #X floatatom 413 145 5 0 0 1 buffer_length_in_seconds - -; #X msg 413 235 resize \$1; #X msg 459 183 22050; #X msg 508 183 44100; #X text 569 185 choose file samplerate; #X obj 79 244 timer; #X obj 79 129 t b a; #X floatatom 79 275 10 0 0 0 - - -; #X obj 413 60 loadbang; #X msg 449 93 \; pd dsp 1; #X msg 413 124 8; #X obj 79 107 symbol; #X msg 152 71 bang; #X floatatom 185 138 5 0 0 0 - - -; #X msg 152 93 64; #X msg 185 94 128; #X msg 218 93 512; #X msg 253 93 1024; #X msg 339 222 const 0; #X obj 507 261 table \$0-samp-1; #X obj 507 287 table \$0-samp-2; #X obj 413 286 s \$0-samp-2; #X obj 413 262 s \$0-samp-1; #X connect 0 0 1 0; #X connect 0 0 10 1; #X connect 2 0 16 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 26 0; #X connect 6 0 27 0; #X connect 7 0 4 1; #X connect 8 0 4 1; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 11 1 0 0; #X connect 13 0 15 0; #X connect 13 0 14 0; #X connect 15 0 5 0; #X connect 16 0 11 0; #X connect 17 0 16 0; #X connect 18 0 0 1; #X connect 19 0 18 0; #X connect 20 0 18 0; #X connect 21 0 18 0; #X connect 22 0 18 0; #X connect 23 0 26 0; #X connect 23 0 27 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hallo! > I tried with > > pd -lib threadlib > > then > > threadlib vers.0.1, library for threaded patching and externals > 2005, by Georg Holzmann mailto:g...@mur.at>> > heavily based on pd_devel code by Tim Blechmann > WARNING: this is very experimental and may crash your patches ! > > > ok. > > > but sndfiler still not working (same error > /usr/lib/pd/extra/sndfiler.pd_ > linux: /usr/lib/pd/extra/sndfiler.pd_linux: undefined symbol: fifo_init > sndfiler > ... couldn't create > ) OK - so then there must be a problem during linking I guess ... I have to look into it. > I like to use your external because ogg files save lots of disk space, > and it's easier to distribute patches with the samples attached... Yes I understand - but OTOH it is much harder do distribute a patch which uses sndfiler, because everyone has to compile it ;) (which can be quite tricky - especially for non-pd experts) > Why can't pd-extended compile sndfiler ? I think I tried to add sndfiler to the pd-extended build system (which should be quite straight forward) a year ago - but did not finish because it has a dependecy to libsndfile - then pd-extended would need to distribute this library as well ... But I agree that this is the way to go, then it should just work. LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
> Hm - did you also load the threadlib external ? (because this is needed) > So you have to _first_ load the threadlib, and the the sndfiler ! > I tried with pd -lib threadlib then threadlib vers.0.1, library for threaded patching and externals 2005, by Georg Holzmann heavily based on pd_devel code by Tim Blechmann WARNING: this is very experimental and may crash your patches ! ok. but sndfiler still not working (same error /usr/lib/pd/extra/sndfiler.pd_linux: /usr/lib/pd/extra/sndfiler.pd_linux: undefined symbol: fifo_init sndfiler ... couldn't create ) > > BTW: if you don't need the threaded soundfiler it is maybe better to just > convert the ogg files to wav and then read it with the normal soundfiler > object ! > I like to use your external because ogg files save lots of disk space, and it's easier to distribute patches with the samples attached... Why can't pd-extended compile sndfiler ? thanx glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hallo! > make -f Makefile.pd_main pd_linux > > with the pd sources of sourceforge svn ... > > I also compiled the threadlib from sourceforge svn (/externals/grh/.) > and seems ok ... Fine ! > But I got an error at puredata (version 041.4 extended 2009 01 21) > > /usr/lib/pd/extra/sndfiler.pd_linux: > /usr/lib/pd/extra/sndfiler.pd_linux: undefined symbol: fifo_init > sndfiler > ... couldn't create Hm - did you also load the threadlib external ? (because this is needed) So you have to _first_ load the threadlib, and the the sndfiler ! BTW: if you don't need the threaded soundfiler it is maybe better to just convert the ogg files to wav and then read it with the normal soundfiler object ! LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hey, now I could compile, I was using the wrong Makefile: make -f Makefile.pd_main pd_linux with the pd sources of sourceforge svn ... I also compiled the threadlib from sourceforge svn (/externals/grh/.) and seems ok ... But I got an error at puredata (version 041.4 extended 2009 01 21) /usr/lib/pd/extra/sndfiler.pd_linux: /usr/lib/pd/extra/sndfiler.pd_linux: undefined symbol: fifo_init sndfiler ... couldn't create some clues? thanx glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] sndfiler - or other ogg audio wavetable object in pd-extended
Hello, Is there new versions of the [sndfiler] object or something similar (an object similar to [soundfiler] that could read ogg sound files into tables ) that comes with pd-extended compilation? Why pd-extended can't compile this? I could not find the object at sourceforge svn and the version at http://grh.mur.at/software/sndfiler.html is not compiling here - make can't find m_fifo.h and g_canvas.h but I could not file those headers at svn sorry if i 'm just lost... thanks glerm ___ 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 are (from the Tk bind() manpage): [snip] ... I'm curious enough to try these out now... just have to dust off my long unused Tcl/Tk skills a bit ;-) >> ... 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
Re: [PD] Pd-extended on AMD 64
Ilias Anagnostopoulos wrote: > > > Has anyone got a > 64-bit binary ready that would be good enough as a > 64-bit release (John Harisson was hosting one)? I have a .deb and corresponding directions for building. The .deb was built on a 64 bit Hardy machine. It worked for my purposes and I didn't find anything broken but I can't say whether it is good enough for release without further testing. Since I made that .deb I updated my machine from 64 bit Hardy to 32 bit Intrepid so I'm not in a great position to continue building and development of a 64 bit release, but I am glad to help out if there is a place for me. .deb and instructions: http://cratel.wichita.edu/cratel/cratel_Pd_extended_on_bit_64_Debian-based_OS (to be moved to the Pd wiki within the week) -John ___ 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
