Re: [PD] Distance Measures among Arrays and Lists
On Fri, Apr 25, 2014 at 12:12 AM, D G mami.mu...@gmail.com wrote: I will check [listtool] and [ptrdiff_t] D - my apologies, ptrdiff_t was a C joke: it's just the type that a C compiler would assign to the difference between two pd array variables (as pointers). it's neither a pd internal nor external object, and its only meaning is in terms of memory addresses; so it's probably not what you're looking for. if you're talking not just about arrays of numeric values but also symbols, you might have to turn to python or lua to compute something like the Levenshtein distance (aka string edit distance). if your argument arrays are always the same length, you can probably twiddle together a fairly simple Pd patch to compute the Hamming distance. marmosets, Bryan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Distance Measures among Arrays and Lists
On Thu, Apr 24, 2014 at 12:59 PM, IOhannes m zmölnig zmoel...@iem.atwrote: On 04/24/2014 11:55 AM, D G wrote: I am very interested in creating a list of objects or abstractions from any PD library (pd-extended or beyond) used to measure the distance between two arrays or two lists. so what's the distance between two arrays? ptrdiff_t ? -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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] text to speech
moin Roman, On 2012-10-10 17:09, Roman Haefeli wrote: There is [flite] from moocow, which is part of Pd-extended (unfortunately broken in Ubuntu 12.04, it seems) how broken? is there any particular error message being produced? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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] Stream of caracters to list of words
moin Fernando, moin list, [... apologies for double-post; forgot to update my client address at work... shame on me! ] sounds like [rattstok] might do what you want. it's part of [ratts], whose sources live at: http://www.ling.uni-potsdam.de/~moocow/projects/pd/ratts-0.08.tar.gz otherwise, you can write a simple regex tokenizer e.g. in python and wrap that in using [py]/[pyext]. a trickier option would be to use a smarter tokenizer for your particular target language(s); see e.g. http://nltk.org/api/nltk.tokenize.html ... or you could roll your own tokenizer using finite-state machines and talk to it live and stream-wise in pd with [gfsm], but that's beyond the scope of this reply ;-) marmosets, Bryan On 2012-08-19 00:06, FernandoG wrote: Hi PD users :) I am working with text to sound transformation using binfile objet and have a question: binfile objetc read a file and then output caracter by caracter every bang recived, i am planning to use not a stream of ascii number rather than a list of them. Then the idea is to use words as control signal for sound sinthesis. How can i get variable lists from a stream? wich objetc can help my? its needed to split the stream in to words and recognize puctuation or space as words limits. Thanks! F -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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] text to sound
there are at least 2 pd interfaces to the flite tts library out there, 1 in svn under ecternals/moocow. there's also ratts, available from ling.uni-potsdam.de/~moocow/projects/pd marmosets, -bryan -- typed with my opposable thumbs! - Original message - Hi, i am developing a proyect where the main idea is transform text data to sound. Time ago i was experimenting with the concept of devices as files in linux where you can read diferent files, like pdf as sound redirecting files to standar output ( by example in bash you can do cat /dev/hda1 /dev/audio to hear the sound of harddisc data) Then i am looking for similar procedures using PD, anybody out there know about a way to transform by explame a pdf or plain text into sound output? i know its a very general question but any help will be apreciated thanks F ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] porting a Pd patch to Max license issues
On 2012-03-16 05:58, Simon Wise wrote: But generally this is not how an end user runs a Max executable ... they do not have Max on their machine, the executable they receive includes all required to run it. There are no Max system libraries to call, and they do not have a Max interpreter on their system. No more does the usual windoof user have a Borland or VisualC compiler installed, nonetheless it's totally legitimate (from the GPL side) to compile GPL code with one of these closed-source, commercial software packages and distribute the resulting executables, provided only that the source code for the *program* remains under GPL -- the GPL doesn't claim that because someone used Borland C to compile a GPL'd program and shared the result that Borland C must be GPL: that would be absurd... Such commercial C compilers also often include local utility libraries with very lax redistribution conditions, so that their users can legally do things like that. The Max license might deal with compiled executables differently or incompatibly; I don't know. p.s. I would be happy if it was. I'd say, but I am not a lawyer, that it certainly is partly the case - GPLed libraries can't be part of standalone executables that are distributed to another party. ... unless the corresponding source of those executables is itself made available under the GPL... with which we're back to system libraries. Sorry if that's bad news for you... as Stallman would very likely not hesitate to point out, __any__ kind of restriction on what your users can or cannot do with your software makes that software less free, and is therefore generally a Bad Thing (at least for the FSF and those who share its interests and goals). Yes ... to _use_ for anything, by anybody, without restriction. But distribution of executables is very deliberately restricted (in a way I personally think is very appropriate), and must be accompanied with the full, properly licensable and reusable under GPL, code for the _whole_ executable. I agree -- in the case of C code it's pretty clear what is meant by library, linking, using, etc., and of course what sort of creatures the system libraries are. For other languages, those terms get murky very quickly. I still think that a system library / interpreter / compiler exception might be made to apply, provided that the package source remained GPL, without trying to infect Max; but it seems to come down to a question of linking vs interpreting/compiling. With this in mind the motivation to port to Max may evaporate. Hmm... if we can keep up the debate on GPL arcana for another few weeks, I'd say it almost certainly will ;-) 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] porting a Pd patch to Max license issues
moin Marco, sounds like a case for the system library exception to me; see here: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs ... my take is that for a (Pd|Max|...) patch, the dataflow interpreter (Pd, Max, or what have you) represents the required system library for use of that patch, so the copyleft doesn't kick in. If you're the copyright holder, you can also always add explicit linking exceptions to GPL'd code, but I think that shouldn't be necessary in this case, since interpreter (Pd|Max|...) and program code (patch) are cleanly separated. marmosets, Bryan On 2012-03-14 13:48, Marco Donnarumma wrote: hey folks, I'm not going to port anything to Max, but someone expressed interest in porting the Xth Sense in Max. Now, apart from my personal view about this, which is a diplomatic I'd rather not, thanks. Port the patch you need to Pd instead. what are the license issues here? The XS framework in Pd will be GPL. Can a Max software be GPL? What about copyleft then? I found this but it's not clear. and I thought there could not be GPL software written in Max because the interpreter is closed-source. http://www.cycling74.com/forums/topic.php?id=1139 and this is nothing new but good and clear resource: http://www.blogherald.com/2009/07/07/the-basics-of-the-gpl/ thoughts, previous cases? -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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] porting a Pd patch to Max license issues
moin Marco, disclaimer i'm not a lawyer and have never even played one on TV. whatever assertions i make in the sequel regarding the GPL and its consequences may be wildly off the mark. /disclaimer ... that said, i *have* spent a lot of time dissecting the GPL recently for my employer (an academic institution) after we had a visit from a certain R. Stallman, and playing through various potential scenarios of interest in preparation for trying to push a GPL release policy to the administration ... On 2012-03-15 12:07, Marco Donnarumma wrote: On Thu, Mar 15, 2012 at 11:05 AM, Marco Donnarumma de...@thesaddj.com mailto:de...@thesaddj.com wrote: thanks for the hint Bryan, that might apply. In this case, porting the code to Max or Max4Live is not legal, unless I specify an additional exception for it, is it correct? quite the opposite: porting GPL'd code to Max or Max4Live is perfectly legal -- the GPL makes no claims on what each licensee does with his or her own private copy of the code -- the copyleft arises only when a licensee wishes to redistribute (convey) his or her changes (i assume you know all this; i'm just being pedantic for paranoia's sake). So, we're talking about distributing changes made to XS with the intent of making XS play together nicely with a proprietary dataflow interpreter (which I'll call Max for simplicity's sake). Since the porter usually holds copyright on the changes, you can't effectively make any restrictions on what they do with those changes, insofar as they're distributed separately from your (GPL'd) code (prototypically as diffs). ... so now we're talking about the porter distributing a package including both XS and the Max-related changes; this __is__ a derivative work in the sense of the GPL, and copyleft kicks in: the corresponding source for the whole package (XS+changes) has to be available under the terms of the GPL as well. Your original question iirc was about problems between GPL and the proprietary Max license; I think the GPL system library exception applies here (for the GPL-Max side; I don't know anything about the Max license, so it might conceivably have problems of its own with even running GPL'd code). GPLv3 (http://www.gnu.org/copyleft/gpl.html) defines system libraries as (boldface inserted by me): The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or *a compiler used to produce the work, or an object code interpreter used to run it*. ... imho, this pretty clearly includes the dataflow environment (Pd|Max) used to run the patch as an exception under the compiler or interpreter clause. The GPL copyleft therefore doesn't extend to these, so there's no conflict with whatever the Max license might be simply by virtue of your original code being GPL. so now, to make it spicier, I found this FAQ: ~ If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the software as it is actually run includes the library. ~ is this a show-stopper for porting of the XS into a proprietary environment? Well, I wouldn't say that Max is using XS in this sense, but rather that Max acts as the interpreter for XS. p.s. I would be happy if it was. Sorry if that's bad news for you... as Stallman would very likely not hesitate to point out, __any__ kind of restriction on what your users can or cannot do with your software makes that software less free, and is therefore generally a Bad Thing (at least for the FSF and those who share its interests and goals). If it's any consolation, I suspect that the legal issues get quite a bit murkier if we consider binary distributions of the (XS+changes) package (if such things exist; I seem to recall having heard about them at some point), since these would assumedly include some part of the Max system libraries as well. There's probably a GPL clause which handles that as well (java class libraries might behave similarly), but I can't seem to turn it up at the moment. marmosets, Bryan On Thu, Mar 15, 2012 at 9:34 AM, Bryan Jurish moocow.bov...@googlemail.com mailto:moocow.bov...@googlemail.com wrote: moin Marco, sounds like a case for the system library exception to me; see here: http://www.gnu.org/licenses
Re: [PD] choosing your language at launch WAS: Japanese Pure Data book is out now.
morning all, apologies for missing this the first time around, and for reviving the topic if the question has already been addressed, but... On 2012-02-25 17:59, András Murányi wrote: If you want the *whole* app to change language, I'm pretty sure it will need to be restarted. Then I guess an equivalent of export LANG can be issued from tcl (and/or C?) at startup. (Could someone with the knowledge confirm/correct this plz?) you can use the [locale] object (probable moocow/locale in pd-extended) to set C99 locale stuff like LANG (or more POSIXly correct, LC_ALL). Use it like: [set LC_ALL de_DE.UTF-8, set LC_NUMERIC C( | [locale] ... note that it's important to keep LC_NUMERIC=C in order to avoid parse errors for locales with funny floating-point conventions (such as de_DE, which uses the comma as a floating-point separator). The C equivalent is just: #include locale.h setlocale(LC_ALL,de_DE.UTF-8); setlocale(LC_NUMERIC,C); Not sure if this helps with changing the gettext-lookups for the running process though; maybe follow it up with an exec() ? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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] choosing your language at launch WAS: Japanese Pure Data book is out now.
On 2012-02-24 23:11, Mathieu Bouchard wrote: Just setting the 2-letter language code is usually wrong, because most people want to also have the country code and encoding as well. For example : export LANG=fr_CA.utf8 selects French, Canada and Unicode UTF-8 all at once. ... unless you've done something like export LC_CTYPE=en_US.ISO-8859-1 or export LC_ALL=C when no one was looking ;-) marmosets, Bryan -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -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 ch...@mccormick.cx 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
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
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 single argument. It returns a truth value; albeit in at least one common sense of 'exist' that value depends on the evaluation index (possible world / place and time of utterance / speaker / etc). I'm talking about the kind of existence which is independent of the current index, i.e. __necessary__ existence: existence in every possible world. Sorry, that was probably annoying. Yes, different people use the word in different ways with different connotations. I was suggesting that small counting numbers are a different kind thing to the other quantities listed here. They are observable in a different way, without the constructs that other
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-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] Abstractions x Externals
On 2011-02-16 14:02:52, Mathieu Bouchard ma...@artengine.ca 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] standard encoding of pd files in each system?
moin again, On 2011-01-30 17:07:44, Mathieu Bouchard ma...@artengine.ca 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't want to go to N*4 there... 4096 MB of DDR3 RAM is currently 37,99 $, going downhill. So, even with N*8, it doesn't look like the end of the word. (l) grr yes yes, point taken, but I find it horribly nasty to waste more than half of the memory allocated (ok, the strings-as-lists-of-floats waste even more, but that's explicit and open about its hackery
Re: [PD] standard encoding of pd files in each system?
moin Mathieu, moin all, On 2011-01-29 17:12:02, Mathieu Bouchard ma...@artengine.ca 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 much text at once in RAM ? Stipulated for most purposes. Taking ratts as an example, the CMU dictionary is only 3.5M, the beep dictionary is 7.6M. The non-free German dictionary BOMP is still only 9.1M. I agree that none of this is going to make the cabbage any fatter, as a saying here goes. In other work, I need much more data. The morphology transducer I use is 153M stored offline. (and more
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 reduz...@gmail.com 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 ma...@artengine.ca 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 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 h...@at.or.at 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] 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. potaxpo...@gmail.com 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] 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 joaomart...@mac.com 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] 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 f...@footils.org 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
[PD] class_sethelpsymbol (was: [folder] external?)
morning all, On 2010-06-25 20:43:38, Hans-Christoph Steiner h...@at.or.at 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 /ydego...@gmail.com/* wrote: From: ydego...@gmail.com ydego...@gmail.com Subject: Re: [PD] [folder] external? To: Jonathan Wilkes jancs...@yahoo.com Cc: Kim Cascone k...@anechoicmedia.com, pd-list pd-list@iem.at 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] 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 potaxpo...@gmail.com 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] [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 de...@thesaddj.com 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] 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 h...@at.or.at 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, martin.pe...@sympatico.ca 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] 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 h...@at.or.at 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] message box issue with blank spaces
moin moin, On 2009-12-09 10:37:10, ypatios ypat...@gmail.com 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] 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 matteosistise...@gmail.com 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] 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 moo...@ling.uni-potsdam.de 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] 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 timv...@gmail.com 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] MinGW/Windows work session - tomorrow, Tuesday 5/18
moin all, On 2009-05-21 18:10:35, Hans-Christoph Steiner h...@at.or.at 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] 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 h...@at.or.at 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] 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 ATT-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 l...@floppy35.de 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] [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 babs...@hotmail.com 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] PdCon09: TeX paper templates
On 2009-03-12 14:01:24, IOhannes m zmoelnig zmoel...@iem.at 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] 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 h...@eds.org 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] 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 h...@eds.org 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 h...@eds.org 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() (I've actually got a version of this too) Other of Bezanson's utilities (isutf8(), u8_offset(), u8_charnum(), u8_nextchar()) are also potentially useful for adapting the C side, and in some cases, I'm not even sure how to wrap them with the C locale functions without converting the whole UTF-8 string to wchar_t, which I think we can agree we do not want to do. Assumedly, Bezanson's code (public domain) code is safe for integration with anything, so I'll use that for now, if no one objects. That said, a faster implementation would
[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 Key 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 h...@eds.org 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 h...@eds.org 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
inline: test-utf8.pngIndex: 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 locale.h
+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, (int)(av[1].a_w.w_float));
+ /*printf(moo: charcode %%d=%d, %%c=%c, %%C=%C\n,
(int)(av[1].a_w.w_float), (int)(av[1].a_w.w_float), (int)(av[1].a_w.w_float));*/
+ /*printf(moo: buf='%s'\n, buf);*/
+gotkeysym
Re: [PD] locales for Pd WAS: japanese encoded chars in PD
moin all,
On 2009-02-13 03:14:20, Hans-Christoph Steiner h...@eds.org 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 h...@eds.org appears to have written: On 2009-02-12 06:24:44, Hans-Christoph Steiner h...@eds.org 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 pi;delta; 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 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
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 h...@eds.org 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 pi;delta; 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 has installed. Here (linux/debian), I can see which locales are installed with: bash$ locale -a ... I would expect goofiness trying to use en_DK.UTF-8 if it's not been installed ... marmosets, Bryan -- Bryan Jurish There is *always* one more bug. jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
Re: [PD] string2any in arduino.pd is now broken
morning all, On 2009-02-12 10:42:10, Frank Barknecht f...@footils.org 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] japanese encoded chars in PD
morning all, On 2009-02-11 03:04:34, Hans-Christoph Steiner h...@eds.org 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 pi;delta; -- 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 locale.h 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
[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] request for objections: any2string - unsigned char
moin all, On 2009-01-18 19:41:06, Roman Haefeli reduzie...@yahoo.de 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 martin.pe...@sympatico.ca 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
Re: [PD] request for objections: any2string - unsigned char
moin moin, On 2009-01-16 15:56:22, Mathieu Bouchard ma...@artengine.ca 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
moin Mathieu, moin all, On 2009-01-15 20:45:13, Mathieu Bouchard ma...@artengine.ca 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 ma...@artengine.ca 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
[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=detailaid=2501709group_id=55736atid=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 ma...@artengine.ca 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] 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=qhl=engeocode=q=7006+N+Glenwood,+Chicagosll=37.0625,-95.677068sspn=58.337319,94.833984ie=UTF8z=17g=7006+N+Glenwood,+Chicagoiwloc=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] 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] 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] 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] 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] 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] 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] 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] 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 josuemoreno1 at hotmail.com 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] [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. rantI 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./rant 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] 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] 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] 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] 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] 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] 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] 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)
) 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] 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
