Re: [PD] Creation Argument Weirdness
Thanks, Matt. I also see that I overlooked a previous thread about this very issue. I guess I shouldn't make a bug tracker entry since it's not clear whether this is desired behavior or not, but I'm curious: does anyone desire this behavior? It just seems obscure that loadbang would bang but disable (non-[pipe]ed) outlets. -Jonathan --- On Fri, 4/10/09, Matt Barber wrote: > From: Matt Barber > Subject: Re: [PD] Creation Argument Weirdness > To: pd-list@iem.at, "Jonathan Wilkes" > Date: Friday, April 10, 2009, 4:34 AM > > > > Hi, > > I think I may have found a bug. After changing the > abstraction > > argument, nothing comes out of the outlet to the > parent patch. I'm on > > windows; can someone confirm before I post it on the > bug tracker? > > > Same over here. As a very limited hack, you can throw a > [pipe 0] in, > but dataflow ordering gets screwed up. See attached. > > M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
sorry, i meant wiki as a shorthand for software revision control, so that there is a trace history of edits and the database can be exported at a given revision. interesting ideas however, i admit i'm not completely familiar with the JSON format, but i do understand the basis behind this request. definitely something to think about. dmotd On Friday 10 April 2009 05:56:54 glerm soares wrote: > 2009/4/9 dmotd > > > what i am interested in developing is a wiki that > > incorporates the pd patcher paradigm, so that reference > > material and examples can be submitted as pd-code. > > This is so far the best solution. > > But why wiki? I think it should be done in a customized CMS, > something made with some python parsers and a MVC web framework > like Django... (Ruby fans will say Ruby on Rails, but you got the > idea)... > > This could be a good reason to think about a > "Puredata_abstraction to JSON"parser, that was discussed in other > thread (DIY GSoC)... Since JSON can be parsed even to a RSS > format easily... See that? Read new patches docs at the RSS news? > > Than also the string issues could be solved editing .pd > documentation in text based editors. And even some web based > WSIWYG editor that would generate "pd readable" > documentation :) > Could be? > > > té+ > > glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] (Ask) Master Degree in New Media Arts
Wow, thank you so much everybody, now I think I have to prepare my portofolio, as you guys have given me so much information on where to continue my study. Thank you very much everyone! :D ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 9, 2009, at 2:33 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : On Apr 8, 2009, at 5:59 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : Inside of the objects themselves, I use always the [mapping/ reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation. do you agree if i change this? Unfortunately, that's not entirely true, otherwise I would say to change it. Right now, a binary object will trump ANY abstraction, even if it is in the same directory. So if someone loads a binary object called "reverse", then [reverse] will ALWAYS be that binary, so matter where you put reverse.pd or how you load it. [mapping/ reverse] prevents that. name clash are bad. curently it's a fact. things may change in the future, but now nameclash must be avoid. since there already are nameclash, it's important for a user to have a full control of the object used. i do this by copying abstraction in my patch folder. it also allow my patch to work latter, when the abstraction have changed. Copying the abstraction into the same folder as the project will not prevent the problem I described above. As things are, that's not a solution. I think it'll work most of time, like most of these methods we discuss back and forth. The namespace prefix like [mapping/reverse] is also not infallable, but it is a lot less likely to be affected by nameclashes, since there would have to be both a folder and a file named the same. It seems to me a good starting place. In any case, nameclashes are an old issue, many people have tackled it, I think we can learn from them and make a Pd-ish implementation of namespaces/import that is not complicated. I think we can make a solution that always works. I am not satisfied with just using the current situation. I've been burned too many times in projects and while teaching workshops and classes by name conflicts. The output~ one is a recent example. .hc This is a perfect case of why we should change the load order in Pd. ok. change it if you wish. but don't find workaround with solution that work only for you. sorry if i'm rude, but i'm more and more irritated by this problem. c I think it should search for all object types in a given path (i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next path. Currently the opposite happens: it searches .pd_linux in all paths, then the loaders (i.e. .pd_lua) in all paths, then the abstractions in all paths. .hc "[W ]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creation Argument Weirdness
> > Hi, > I think I may have found a bug. After changing the abstraction > argument, nothing comes out of the outlet to the parent patch. I'm on > windows; can someone confirm before I post it on the bug tracker? Same over here. As a very limited hack, you can throw a [pipe 0] in, but dataflow ordering gets screwed up. See attached. M abstraction.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creation Argument Weirdness
yeah weird. same thing here. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Creation Argument Weirdness
Hi, I think I may have found a bug. After changing the abstraction argument, nothing comes out of the outlet to the parent patch. I'm on windows; can someone confirm before I post it on the bug tracker? Thanks, Jonathan patch.pd Description: application/puredata abstraction.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd FLOSS Manual Update pt 1
Hey Glerm, no problem to borrow, as it's GPL, etc etc. However, if you wanted to engage in actual proper translation then then organization and infrastructure of FLOSS Manuals would be at your disposal. Best to wait until there are some 1.0 and later 2.0 (with sensors, networking, GEM, MIDI, etc) versions to translate of course. But I think Brazilian translation would be a very cool first translation of the releases. Maybe Adam Hyde from FLOSS Manuals could offer some suggestions on how to do it as well. They are actually busy writing a manual on how to translate manuals I believe... best! D. glerm soares wrote: 2009/4/9 glerm soares mailto:organi...@gmail.com>> Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started... In fact, I don't think I will "translate" litteraly, but use as some kind of guide for topics, and maybe use some pictures and examples... Any problem? -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 169: "Use filters" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd FLOSS Manual Update pt 1
2009/4/9 glerm soares > Since it's GPL, > I will translate some of them to brazilian portuguese and put into > http://artesanato.devolts.org website, ok? This is a new brazilian hacklab > weblog we just started... > In fact, I don't think I will "translate" litteraly, but use as some kind of guide for topics, and maybe use some pictures and examples... Any problem? see ya glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd FLOSS Manual Update pt 1
Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started... I should also put it into the http://pt.flossmanuals.net if it could be set, but I think this is an issue to the floss manuals mailing list, right? I will ask for it there when I see that the job will really be done... Then I could try to ignite a local "sprint" also, and give a help about PDcon 09 rumours... Thanks all of participants for the efforts, you know all the compliments deserved. see ya best regards, glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
2009/4/9 Rich E > > > > Writing this patch in python with the current format would just be > messy. Doing it in JSON or YAML would be straightforward. > > Maybe, as more of a proof of concept, a JSON->pd format file converter > can be made? > Could be done for a customized CMS for web documentation, something made with some python parsers and a MVC web framework like Django... (Ruby fans will say Ruby on Rails, but you got the idea)... This could be a good reason to think about a "Puredata_abstraction to JSON"parser, as was discussed in other thread (Pdpedia and random generation )... Since JSON can be parsed even to a RSS format easily... See that? Read new patches docs at the RSS news? Than also the string issues could be solved editing .pd documentation in text based editors. And even some web based WSIWYG editor that would generate "pd readable" documentation :) Could be? té+ glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
2009/4/9 dmotd > > what i am interested in developing is a wiki that > incorporates the pd patcher paradigm, so that reference material > and examples can be submitted as pd-code. This is so far the best solution. But why wiki? I think it should be done in a customized CMS, something made with some python parsers and a MVC web framework like Django... (Ruby fans will say Ruby on Rails, but you got the idea)... This could be a good reason to think about a "Puredata_abstraction to JSON"parser, that was discussed in other thread (DIY GSoC)... Since JSON can be parsed even to a RSS format easily... See that? Read new patches docs at the RSS news? Than also the string issues could be solved editing .pd documentation in text based editors. And even some web based WSIWYG editor that would generate "pd readable" documentation :) Could be? té+ glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd and recent jackd
Hi! joel silvestre schrieb: I'm afraid there's something wrong with Pd and new jackd releases (0.116.x). Pd gives some ; watchdog: signaling pd... and audio dropouts. The watchdog errors appears only on a gui-less pd, I can't say if it's the same for dropouts as the gui is likely to produce some audio clicks. This might be the same issues which bothered me some time ago. Try running jack using '-R' and '-P' parameters together like: jackd -R -P 15 -d alsa You can also set -P in qjackctl For me everything above 11 worked without these errors on alsa, for firewire audio I had to set it slightly higher. Also have a look at what roman said in this thread, which was quite helpful: http://lists.puredata.info/pipermail/pd-list/2009-04/069267.html cheers, Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
moses 0 filter also negative arguments, they usually are unwanted. but of course sel 0 is used the rest of the time. c IOhannes m zmoelnig a écrit : cyrille henry wrote: Hans-Christoph Steiner a écrit : ... If there is good code out there, I want to use it, not reinvent it. having a complex abstraction to replace this : loadbang $1 moses 0 shouldn't that be [select 0] rather than [moses 0] ? mfgasd.r IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
well, to host a convention here is definately and effort to put S.America in the game. What you are discussing feels to me like one of the best issues to raise up in Round Tables. Actually, Round tables were said to be proposed here on the list, so lets talk about this more later on. I am up for parties alright... 2009/4/9 Jean-Noël Montagné : > > Salut Hans and PD community > > First of all, thank you very much for all work you have done for the idea > and server services. I am very busy for working for living, but also for > Bricolabs.net projects ( bricophone.org, fluxtation.org, oswash.org), and I > still can't handle the pdpedia project yet. > > I think there could be newcomers to PD ready to assume this kind of > responsability, individually or collectivelly. Did I have understood that > Alexandre Porres and other PD users from Brazil could help us to find some > people in south america ? > it would be good to displace more the center of gravity of PD users in > direction of the south ! and for many reasons Brazil will be the next PD > country/community... > Some people also have some grants to work on open source, wich is impossible > in France for example... > The profile needed is someone able to do some Wikipedia maintaining and > hacking. > > Cheers, > JN > > PS: what about a giant multilingual PDpedia party, PDFlossManual Party, > PDVideopediaParty in the next PDconvention ? > > >> There are lots of good ideas worth trying. We've talked about it a lot, >> we just need someone to take charge of it. I am just too overloaded to >> handle pdpedia on top of everything else. Who wants to own it? >> >> .hc > -- Alexandre Torres Porres cel. (11)8179-6226 Website: http://porres.googlepages.com/home http://www.myspace.com/alexandretorresporres ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd FLOSS Manual Update pt 1
I have to teach in the end of the month, it will be a nice opportunity to proof read this before, and collaborate with the feedback you want. GOOD JOB! cheers On Thu, Apr 9, 2009 at 1:40 PM, Derek Holzer wrote: > Dear list, > > the book sprint for the Pd FLOSS Manual last weekend went very well! Several > writers and proofreaders joined us at each location in New York City and > Berlin, as well as remote contributors online (see contributors below). > > The good news is that quite a lot of content was generated over the weekend, > including the beginnings of entirely new sections on GEM, MIDI, Network Data > and Sensors. You can see the work-in-progress FLOSS Manual via the editing > interface here: > > http://en.flossmanuals.net/bin/view/PureData/WebHome > > The not-so-good news is that most of these new sections are in limbo! Next > month, Adam and I hope to publish version 1.0 of the Pure Data FLOSS Manual > to the front page of the FLOSS Manuals site for public viewing: > > http://en.flossmanuals.net/ > > The chapters that will be included in Version 1.0 will be: > > INTRODUCTION > INSTALLING > GETTING STARTED > THE INTERFACE > AUDIO TUTORIALS > DATAFLOW TUTORIALS > STREAMING > LIST OF OBJECTS > APPENDICES > > But in order to do this, some of the chapters in each section need some > improvement. Here's what needs to happen immediately. Please take a look and > see if you can help! > > ALL CHAPTERS > --Proofreading for spelling, simplicity, new-user-friendliness and > consistent tone (see INSTALLING, GETTING STARTED, THE INTERFACE and AUDIO > TUTORIALS chapters for style and format examples). > > AUDIO TUTORIALS___ > > -> This section is almost done. What remains is to make a proper tutorial > out of it... i.e. that the examples in the chapter follow a "story" which > leads up the construction of a simple synthesizer. Due to changes in > structure of the chapters inside, this needs updating, but I will work on > it. > -> In general, structure, tone and content of these chapters should serve as > guide for the rest of the manual. > -> I would like to see all sections follow this tutorial model, of building > up a project from the various elements introduced in each chapter. > -> keep in mind that other sections (such as MIDI, NETWORK DATA, SENSORS, > etc) can build on examples started in this chapter, so that the whole manual > is interconnected and has a proper "storyline". > > * http://en.flossmanuals.net/bin/view/PureData/Tables > --where does this go? Dataflow or Audio? (Audio I think) > --Would be good to integrate with > http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables > --I'd like to crop screenshots to get rid of menu bar > --Incomplete, needs expansion and also "loop it" and "play sections" parts > --Could this also be structured like tutorial rather than taxonomy? > > DATAFLOW > > * http://en.flossmanuals.net/bin/view/PureData/Messages > --Looks very good! > > * http://en.flossmanuals.net/bin/view/PureData/Math > --"I guess it isn't necessary to explain how [+], [-], [*] and [/] work. " > Check for tone. > --Bit twiddling: empty > --Expr: empty > --Audio math: empty > > * http://en.flossmanuals.net/bin/view/PureData/Lists > --Needs more than taxonomy, i.e. real world examples! > > * http://en.flossmanuals.net/bin/view/PureData/OrderOfOperations > --Needs a little attention, but I'm not sure, maybe simpler examples, > clearer screenshots, explain object abbreviations in-line if used > > * http://en.flossmanuals.net/bin/view/PureData/WirelessConnections > --Examples too busy, need to be simpler!! > --Text doesn't really connect to examples > > * Subpatches, Abstractions & Dollarsigns > --These should all be in one chapter, explaining how to make reusable > patches with nice interfaces, rather than atomized into different > chapters(title = Patch Management?) > > * http://en.flossmanuals.net/bin/view/PureData/Subpatches > --Needs final real world example, maybe in connection with abstractions + > GoP > > * http://en.flossmanuals.net/bin/view/PureData/Abstractions > --Tie in with Patch Management (to be created) > --Better examples! > > * http://en.flossmanuals.net/bin/view/PureData/DollarSigns > --Get rid of this chapter, confusing collision with dollar signs in messages > --Better examples, explained in-line in text > --Tie in with Patch Management (to be created) > --All examples are not saved anywhere! > > * http://en.flossmanuals.net/bin/view/PureData/GraphOnParent > --Move to Patch Management (to be created) > --Not completely explained (colored background canvas) > --No colors in Pd patch screenshots please! > > * http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables > --Check text for clarity, accuracy, simplicity > --Redo screenshots with antialiased text please! > > ___LIST OF OBJECTS > -> Table format doesn't work in some browsers (Adam Hyde will look into > this) > > GLOSSARY > -> HTML tables don't work well here, Ad
[PD] pd and recent jackd
Hi all, I'm afraid there's something wrong with Pd and new jackd releases (0.116.x). Pd gives some ; watchdog: signaling pd... and audio dropouts. The watchdog errors appears only on a gui-less pd, I can't say if it's the same for dropouts as the gui is likely to produce some audio clicks. Everything performs well with old jackd ver 109.2. I tried different revision of pd-extended from 0.39.2 to 0.41.4, watchdog and dropouts are here.. All the best Joël ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] writing to iowarrior in pd
hi list! for a while now, i am trying to hook my iowarrior56 (from codemercs.com) up with pd, running on my OSX10.4. i have no problems with reading the state of the pins using the HID object in pd. but now i would like to reverse it (or: switching the pin-states on and off, controlled from pd to the iowarrior). but so far, i didnt succeed with that at all. while looking on the internet for clues, i came across the same question in an old thread of this list. i have read that there's a possibility that there should be an external written for it. the sdk is released on the codemercs-site, and word on the streets tells me that it should be simple...but since i have practically zero experience with c-programming (or writing externals for pd for that matter), i have no clue to do that. therefor my question: could i just use the HID-object (but what should the arguments then be for writing the pins?), or maybe some other known object? (since this iowarrior is similar to the arduino series, maybe the pduino-object could work. but then again, the arduino probably would use other arguments) or, perhaps someone already wrote an external for it? thanks in advance! twan _ Rediscover Hotmail®: Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile1_042009___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Apr 6, 2009 at 8:06 PM, Mathieu Bouchard wrote: > On Mon, 6 Apr 2009, Chris McCormick wrote: > >> No, that's not at all the reason I think that a format like JSON or YAML >> would be useful. It's more to do with patches being more widely and easily >> parseable, mashable, etc. It's to do with interoperating with more programs >> than just Pd itself. Sure, we could do this and that, and we could use 'a >> bit of imagination' but the current format of Pd patches is not friendly or >> popular. I'd rather have a patch format that plays nice with other programs >> and is easily human readable. > > Ok, you know what playing nice means and what human readable means, I can't > help you with that at all. I didn't watch the infomercials about JSON, so I > don't know how amazingly easier than everything else it is. I sometimes would like to write a part of a patch in python, like say all the audio files in one directory, each in a seperate array, and then load it in pd. This can be done completely in pd, but for reasons I don't yet understand (other than it is quite easy to crash pd when dynamic patching), it is not widely supported. Writing this patch in python with the current format would just be messy. Doing it in JSON or YAML would be straightforward. Maybe, as more of a proof of concept, a JSON->pd format file converter can be made? regards, Rich >> How many parsers are there which read Pd patches? One mainly, maybe other >> obscure ones which I don't know about, and some that I have written which >> nobody knows about. How many parsers are there for the JSON format? >> Hundreds, >> in hundreds of different languages. > > After the parser is ready, you still have to write the programme that will > actually do something useful with the patch that has been read and parsed, > and that will most likely the part of the work that will be the most > significant, especially if you don't bother about handling backslashed > spaces properly, because pd doesn't anyway. > > If you already have a [netreceive] in the target language, you already have > a parser for much of the pd format... > >> Yep, I get what you are saying, but you are unfortunately wrong. Nobody >> cares about Pd's syntax except our small band of merry Pd people. > > So why would those people who don't care about Pd's syntax would ever care > about processing Pd patches? It just doesn't make any sense. > >> Even your point about not knowing how JSON (or YAML or whatever) is going >> to be used is irrelevant because of the gain in interoperability with other >> programs and people. > > I don't think any interoperability is going to be gained from using a > JSON-based format (that you still haven't specified) because no non-Pd > people will want to process patches. Forget everything about the format > being readable by real human beings (by opposition to those damn pd users), > a JSON-based patch format will only achieve one thing, allow the JSON fans > to say that Pd supports JSON. > >> Yes, that's very true. I guess with the idea of a very social format like >> YAML or JSON > > Once you consider the actual number of XML/YAML/JSON users who would be > processing any pd patch if it were coded in their favourite encoding, then > you wouldn't feel nearly as lonely with the Pd format, really. I'm expecting > you to be disappointed by what JSON will bring to Pd. > > In any case, it's still easy to make a Pd-to-JSON converter, so, invent > yourself a suitable JSON-subformat for converting your Pd patches to, and > see whether any JSON user cares, and it will save us having to convert all > of our patches to JSON, really. > >> I am trying to advocate a language that interoperates nicely and easily >> with other languages and hence isn't a small island of software > > Be careful of all of the "details" of the software, which is everything else > that isn't already covered by JSON, which is almost everything of what makes > a patch a patch and what makes pd pd (or what makes some other patching > system be what it is). The superficial part of the syntax is superficial but > it's easy to exaggerate it at the expense of all of the depth of the syntax. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Pd FLOSS Manual Update pt 2
So here is part two!
The following chapters were newly created during the Book Sprint. We'd
really like to see them come together, but we don't think they will be
anywhere near ready before we decide to publish the version 1.0. Futher
work on these chapters is also appreciated, but only after the chapters
we have marked for inclusion in the 1.0 are complete. Writing, editing
and proofreading on these chapters can continue as normal, and when we
are ready for a second release (now with GEM + SENSORS!) then we will
include them.
CHAPTERS FOR FURTHER DEVELOPMENT, not to be included in upcoming 1.0
release:
GEM
SENSORS
MIDI
NETWORK DATA
When the version 1.0 is completed, and these chapters are also fixed,
then we can consider a paper publication!!
Here are the issues and places for improvement on each chapter. Again,
we welcome improvements to these chapters, but if you are going to spend
any time on this manual in the next few weeks, it would make more sense
to focus on the chapters marked for publication (see Part 1 of this update):
GEM_
-> These chapters need a lot of work to be anywhere near complete!
-> My suggestion is to do more tutorial-based stuff, like "how to"
sections, rather than break down the material by taxonomy (which is how
it is already documented elsewhere). Thus, "How to VJ with Images and
Video using GEM" and "How to Create 3D Animations using GEM" would be
preferable to existing system.
-> Perhaps rather than single GEM heading, each of these could be
section heading with chapters beneath them? In such a case, the chapters
beneath each section should follow some logical progression from one to
the other, leading towards the goal of VJing or doing animations.
-> Also some of the examples are far too complex, and rely on arcane
systems like [import] or objects with severe nameclashes like [counter]
which are traps for new users and should be avoided!
* http://en.flossmanuals.net/bin/view/PureData/GEMIntroduction
--Check for tone, perhaps more introduction and less credits, explain
basic parts better (i.e. "2D and 3D graphics and animation, realtime
image and video processing, and particles")
--Show screenshot of help patches + examples in Pd Browser?
* http://en.flossmanuals.net/bin/view/PureData/GEMBasics
--Mention "Red Book" and other technical OpenGL info later, it's not
needed in beginners introduction, skip immediately to rendering
--Re: [gemwin] question in text ("is this true?"): please verify this
information or cut it!
--In general, would be good to concentrate on doing things rather than
exhaustively explaining technical details
--Re: [pix] objects save this for chapter on it.
--Perhaps what is needed here is overview of GEM functions, and then
each chapter can deal with them independently as part of unified
tutorials (VJing/Animation)
--Section (or new chapter) on setting up second screen for live
performance for each OS!
* http://en.flossmanuals.net/bin/view/PureData/GEMImagesMoviesAndVideo
--This could really use less of reprinting helppatches, and more how to
do things, like:
Using [metro]/[float] counter to drive frame playback (changing
playback speed or going backwards)
Using [mod] and [+] to create smaller loops within film
Use [random] to "granulate" film
Use pix effects (where to insert in gemlist)(then refer to later
chapter for more details, or work into single VJ tutorial as suggested
above)
--Section on video formats for each OS is essential
* http://en.flossmanuals.net/bin/view/PureData/GEMVideoMixer
--I would like to see [alpha] plus [colorRGB] used in how to do simple
crossfader instead of [pix_mix].
--Explanations could be helped more towards clarity.
--Re: recommendation to "create abstractions": either explain this
inline or direct reader to Patch Management section (to be created)
which will cover subpatches, abstractions, etc
--Webcam: needs Linux info on getting video devices in, there are
probably other flags which need to be shown as well
* http://en.flossmanuals.net/bin/view/PureData/GEMPixEffects
--Please don't use a PiDiP object [colorgrid] in a GEM tutorial!!!
(Also not cross platform!)
--Can this tutorial be done without need to import? (i.e. used normal
counter instead of external?) I really don't agree with using objects
that have such bad name clash issues, like [counter]
--The [send] and [receive] are abbreviated (first bad) and not explained
in tutorial (second bad)
--In general, examples are too complex, please simplify!
* http://en.flossmanuals.net/bin/view/PureData/GEMSavingAndRecording
--Same problem as above, please don't [import] as it makes it much more
complicated to explain whole patch. Basic objects available in
Pd-Extended are assumed, anything else should either be skipped or
extensively explained in line!
--While the toggle for turning gemwin on and off is useful, it is not
explained in line and in general add
[PD] Pd FLOSS Manual Update pt 1
Dear list, the book sprint for the Pd FLOSS Manual last weekend went very well! Several writers and proofreaders joined us at each location in New York City and Berlin, as well as remote contributors online (see contributors below). The good news is that quite a lot of content was generated over the weekend, including the beginnings of entirely new sections on GEM, MIDI, Network Data and Sensors. You can see the work-in-progress FLOSS Manual via the editing interface here: http://en.flossmanuals.net/bin/view/PureData/WebHome The not-so-good news is that most of these new sections are in limbo! Next month, Adam and I hope to publish version 1.0 of the Pure Data FLOSS Manual to the front page of the FLOSS Manuals site for public viewing: http://en.flossmanuals.net/ The chapters that will be included in Version 1.0 will be: INTRODUCTION INSTALLING GETTING STARTED THE INTERFACE AUDIO TUTORIALS DATAFLOW TUTORIALS STREAMING LIST OF OBJECTS APPENDICES But in order to do this, some of the chapters in each section need some improvement. Here's what needs to happen immediately. Please take a look and see if you can help! ALL CHAPTERS --Proofreading for spelling, simplicity, new-user-friendliness and consistent tone (see INSTALLING, GETTING STARTED, THE INTERFACE and AUDIO TUTORIALS chapters for style and format examples). AUDIO TUTORIALS___ -> This section is almost done. What remains is to make a proper tutorial out of it... i.e. that the examples in the chapter follow a "story" which leads up the construction of a simple synthesizer. Due to changes in structure of the chapters inside, this needs updating, but I will work on it. -> In general, structure, tone and content of these chapters should serve as guide for the rest of the manual. -> I would like to see all sections follow this tutorial model, of building up a project from the various elements introduced in each chapter. -> keep in mind that other sections (such as MIDI, NETWORK DATA, SENSORS, etc) can build on examples started in this chapter, so that the whole manual is interconnected and has a proper "storyline". * http://en.flossmanuals.net/bin/view/PureData/Tables --where does this go? Dataflow or Audio? (Audio I think) --Would be good to integrate with http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables --I'd like to crop screenshots to get rid of menu bar --Incomplete, needs expansion and also "loop it" and "play sections" parts --Could this also be structured like tutorial rather than taxonomy? DATAFLOW * http://en.flossmanuals.net/bin/view/PureData/Messages --Looks very good! * http://en.flossmanuals.net/bin/view/PureData/Math --"I guess it isn't necessary to explain how [+], [-], [*] and [/] work. " Check for tone. --Bit twiddling: empty --Expr: empty --Audio math: empty * http://en.flossmanuals.net/bin/view/PureData/Lists --Needs more than taxonomy, i.e. real world examples! * http://en.flossmanuals.net/bin/view/PureData/OrderOfOperations --Needs a little attention, but I'm not sure, maybe simpler examples, clearer screenshots, explain object abbreviations in-line if used * http://en.flossmanuals.net/bin/view/PureData/WirelessConnections --Examples too busy, need to be simpler!! --Text doesn't really connect to examples * Subpatches, Abstractions & Dollarsigns --These should all be in one chapter, explaining how to make reusable patches with nice interfaces, rather than atomized into different chapters(title = Patch Management?) * http://en.flossmanuals.net/bin/view/PureData/Subpatches --Needs final real world example, maybe in connection with abstractions + GoP * http://en.flossmanuals.net/bin/view/PureData/Abstractions --Tie in with Patch Management (to be created) --Better examples! * http://en.flossmanuals.net/bin/view/PureData/DollarSigns --Get rid of this chapter, confusing collision with dollar signs in messages --Better examples, explained in-line in text --Tie in with Patch Management (to be created) --All examples are not saved anywhere! * http://en.flossmanuals.net/bin/view/PureData/GraphOnParent --Move to Patch Management (to be created) --Not completely explained (colored background canvas) --No colors in Pd patch screenshots please! * http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables --Check text for clarity, accuracy, simplicity --Redo screenshots with antialiased text please! ___LIST OF OBJECTS -> Table format doesn't work in some browsers (Adam Hyde will look into this) GLOSSARY -> HTML tables don't work well here, Adam Hyde will reformat text with , and ...and finally, THE CONTRIBUTORS! Here are the folks that helped us rock last weekend, in no particular order: AdamHyde DerekHolzer HansChristophSteiner ScottFitzgerald VincentRioux PatrickDavison JoaoPais ServandoBarreiro KorayTahiroglu MariusSchebella JeremySchaller MaxNeupert EvanRaskob GeorgWerner AlexandrePorres JayMaechtlen RomanHae
[PD] formatting replies (was: Re: beat detection)
Could you please try to avoid pasting the entire Pd-List Digest in your reply? -- http://benbakersmith.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] embedded preferences...
I think this is a good idea, but don't know in detail how to do it. Patches should be able to have a say as to what they "prefer" (beyond what's available via the declare object) but they can't just smash over everything - for instance, they might not know what audio device they should use. O've started putting local config files in some of my patches for which I have versions for 3 different audio setups the patch has to run in - I just use loadbang and textfile :) Miller On Thu, Apr 09, 2009 at 12:56:09PM +0200, IOhannes m zmoelnig wrote: > hi all. > > i was wondering what the status of "embedded preferences" (that is: > using a local preference file that is attached with a certain > Pd-application rather than the global preferences valid for all Pd's on > the system) for all platforms and the various tastes of Pd was. > > i know that you can embed a preference file in an osx-bundle in > Pd-extended (at least since 0.40), and iirc this embedding has been > accepted into Pd-vanilla as well (since version ?) > > i seem to remember that a similar mechanism exists on linux. > > i cannot remember anything about w32 (which might be more complicated, > given that with w32 we are using the registry rather than a file that > ships with Pd) > > so my question is: > - is embedding preferences supported on all platforms? > - is embedding preferences supported on both Pd-vanilla and Pd-extended? > - what is the minimum version of Pd i need to acquire the usufruct (with > regard to taste) > > > fgamdsr > IOhannes > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] beat detection
Aha, yes, now found and I downloaded Jamie's Postlude, but the tar.bz2 wouldn't even decompress correctly? Mac OS 10.4 JS ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] beat detection
aubio is available at Jamie's Postlude Distribution of Pd-Extended for mac os only But it is not working here with me... jamie? cheers On Thu, Apr 9, 2009 at 11:31 AM, wrote: > Send Pd-list mailing list submissions to > pd-l...@iem.at > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > pd-list-requ...@iem.at > > You can reach the person managing the list at > pd-list-ow...@iem.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > > Today's Topics: > > 1. new arduino mega (Jose Luis Santorcuato) > 2. Re: Pdpedia and random generation (dmotd) > 3. Re: Pdpedia and random generation (dmotd) > 4. Re: Pdpedia and random generation (dmotd) > 5. Re: beat detection (J. Simon van der Walt) > > > -- > > Message: 1 > Date: Thu, 9 Apr 2009 09:58:23 -0400 > From: Jose Luis Santorcuato > Subject: [PD] new arduino mega > To: PD List > Message-ID: > <4345df630904090658r4bf4f1a4g26c2daa6ec7ee...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > HI everybody... the new arduino mega is here, but i think the ide program > and the pduino object must update...Hans is possible or is possible > change parameteres in firmata and pduino??? well... just a questions... > > Have a nice day friends > > Check the blog... the firts video in in Spanish and the secon English > > Thanks a lot > > Cheers from Chile > > Jos? Luis > > -- > http://arselectronicachile.blogspot.com/ > www.myspace.com/santorcuato > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://lists.puredata.info/pipermail/pd-list/attachments/20090409/2aa048f9/attachment-0001.htm> > > -- > > Message: 2 > Date: Fri, 10 Apr 2009 00:07:43 +1000 > From: dmotd > Subject: Re: [PD] Pdpedia and random generation > To: marius schebella > Cc: pd-list@iem.at > Message-ID: <20090417.43420.dm...@gmx.net> > Content-Type: text/plain; charset="iso-8859-1" > > hey marius, > > okay, well i think we're on the same page here, what you describe > and what's in my head seem to be somewhat aligned. i have a little > bit of time spare at present and a fair bit of experience > developing web based content management systems, so hopefully these > ideas could gather a little momentum. > > what is important here is that there is a layer that is consistent > between all interfaces connecting to it (ie. the database), and the > way that this inforation is organised and presented can vary > depending on the interface. > > it is also very important to make sure that the reference is > maintainable, and where possible self documenting. this is where > your data mining experiments are valuable, any statistics that we > can easily gather, help to build the picture of how pd operates, > and could certainly aid in the development of pd into the future. i > know there is a limit to what can be automated and often automated > content is more of a pain than a help, but a few small things may > help with maintenance issues. > > for example plugging into the output of CIA (which pd is a > subscriber to), should allow the object database to easily monitor > changes to the svn, which in turn could create a section > of 'watched' objects that would provide a list of known changes to > objects (however small) and warn potential contributors that the > object internals have changed and the reference may need to be > updated. > > when i initially started building my own database, i wanted to have > a little picture of the object being described, with all of its > inlets and outlets present. i decided to draw this using GD (a php > graphing app), but in order to do so i had to document the inlets > and outlets that were present, and those that were created > dynamically on init - which meant documenting the init arguments > too. this small exercise in futility helped expand the reference to > include a bit more detail on each class, which i now recognise is > invaluable to the database (and myself) having a stronger knowledge > of pd internals. and now i have something that could potentially > draw *basic* pd patch code without having to use pd as a server, or > analyse pd patches with finer precision. > > another example, i used your CSV file to build a small sh script > that can analyse a pd
Re: [PD] beat detection
Oddly enough, having had some success with BBCut in SC, I was thinking about asking about beat tracking in Pd also. This looks interesting; > [aubioonset~] > | > [rhythm] but... so far I've figured out that aubio doesn't seem to be included in Pd-extended, that it comes from http://aubio.org/, but beyond that I'm finding it hard to track down info on what to do next. Any hints as to how to install it? Ideally an intel binary for OS X 10.4, plus a windows version as well? Thanks, JS ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
On Thursday 09 April 2009 23:14:28 Frank Barknecht wrote: > Hallo, > > dmotd hat gesagt: // dmotd wrote: > > i am not at all convinced that pdpedia/mediawiki serves as a > > good method for object reference. it is difficult to maintain > > (a lot of manual copy and paste), its search/sort functionality > > is limited, the up/down stream api is severely lacking and most > > of all it is difficult to integrate it into a pd environment > > (outside of simple pddp links which are usually inside the > > object reference anyhow). > > I believe, reference documentation belongs into the code and > additional display methods should be generated from that. What's > currently useful in pdpedia mostly was generated by a script, but > a year or so ago and it may already be outdated or referring to > objects not available anymore (i.e. > http://wiki.puredata.info/en/mapping/degrees0x2d0x3emapping) > > Ciao hey frank, yes this is exactly my point, though pd is not the first language to find methods referenced in documentation are severely outdated. and pd is not a text-based language, so text based documentation is already a hurdle. what i am interested in developing is a wiki that incorporates the pd patcher paradigm, so that reference material and examples can be submitted as pd-code. how this is dismantled and presented in text w/ diagrams is irrelevant as long as the folks looking at a text based reference understand that a greater depth to the same reference exists within pd. hopefully something a little more personalised to the pd project can come from these qualms/observations :) cheers, dmotdf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
On Thursday 09 April 2009 23:55:11 marius schebella wrote: > 2009/4/9 Frank Barknecht : > > Hallo, > > > > dmotd hat gesagt: // dmotd wrote: > >> i am not at all convinced that pdpedia/mediawiki serves as a > >> good method for object reference. it is difficult to maintain > >> (a lot of manual copy and paste), its search/sort > >> functionality is limited, the up/down stream api is severely > >> lacking and most of all it is difficult to integrate it into a > >> pd environment (outside of simple pddp links which are usually > >> inside the object reference anyhow). > > > > I believe, reference documentation belongs into the code and > > additional display methods should be generated from that. > > hi frank, > please be more elaborate. are you distinguishing between > reference and documentation? is "reference documentation" the > help patches or some other kind of object reference. are you > talking about code comments? in help patches? or in the C code? > > I think that the purpose of documentation is to teach/explain how > to use objects? reference might be something slightly different. > > the problem imho is that there is no basis right now on which an > automatic documentation generation could build on. I also think > that autogeneration would be extremely helpful, but... who of the > vanilla/external-developers will reliably stick to any rules? > since developers are bad documentators but you still propose that > code should be the source to generate documentation, how do you > think people (who would like to do some documentation) should > contribute? directly to the source code? > > how do you envision that users will search for objects? where do > you think information like tags, similar objects, example patches > should come from? > > marius. i'd love to see as much documentation, tags, categories, etc coming directly from the c code itself, heck.. why not even build a pd class library that stores all of this extraneous info internally! but really with the current codebase it is not feasible to make old objects adhere to some new documentation api subset, and unlikely that new object writers would adhere to that anyhow. that's why its important to make documenting pd as simple as possible and as straight forward as contributing to any wiki for text. frank! your list-abs dynamic reference system is awesome.. that sort of thing should be encouraged everywhere, great job! dmotd ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
hey marius, okay, well i think we're on the same page here, what you describe and what's in my head seem to be somewhat aligned. i have a little bit of time spare at present and a fair bit of experience developing web based content management systems, so hopefully these ideas could gather a little momentum. what is important here is that there is a layer that is consistent between all interfaces connecting to it (ie. the database), and the way that this inforation is organised and presented can vary depending on the interface. it is also very important to make sure that the reference is maintainable, and where possible self documenting. this is where your data mining experiments are valuable, any statistics that we can easily gather, help to build the picture of how pd operates, and could certainly aid in the development of pd into the future. i know there is a limit to what can be automated and often automated content is more of a pain than a help, but a few small things may help with maintenance issues. for example plugging into the output of CIA (which pd is a subscriber to), should allow the object database to easily monitor changes to the svn, which in turn could create a section of 'watched' objects that would provide a list of known changes to objects (however small) and warn potential contributors that the object internals have changed and the reference may need to be updated. when i initially started building my own database, i wanted to have a little picture of the object being described, with all of its inlets and outlets present. i decided to draw this using GD (a php graphing app), but in order to do so i had to document the inlets and outlets that were present, and those that were created dynamically on init - which meant documenting the init arguments too. this small exercise in futility helped expand the reference to include a bit more detail on each class, which i now recognise is invaluable to the database (and myself) having a stronger knowledge of pd internals. and now i have something that could potentially draw *basic* pd patch code without having to use pd as a server, or analyse pd patches with finer precision. another example, i used your CSV file to build a small sh script that can analyse a pd patch and an abstraction folder, and list missing objects (and unique objects for that matter) required for that patch. with a bit more work this could very easily direct users to the libraries they're missing. (i realise that loading the patch into pd spits out this sort of information anyway, but there are times where i would like to check this first - and yes running pd-extended probably sorts out everything anyway, but that isn't always possible). while the current list of objects and abstractions is quite intimidating, getting at least the object list completed and finding methods to extract the rest may be quite easily achieved. i think as you say making this database as approachable as possible to users, so that they can upload, comment, rank and favourite patches/abstractions/objects, will make pd generally a more inclusive environment and something that becomes a solution to more peoples problems. in a sense the more people that are contributing to higher level projects, the more interest there is in documenting the lowerlevel objects. i think this is in a sense where hcs is at with pd-extended, but what is missing with pdpedia/plone. for me the plone space is buried in the logic of private spaces - places to hold your projects (home folders), but not really to mass distribution in a true wiki sense, or as you describe it a 'youtube' space (which is indeed a better metaphor for the distribution of patches/objects/libs etc) so yeah.. this seems to be a shared interest and something potentially to build upon.. on a side note, i took up this project a few years ago when pddb finally breathed its last breath, which for me was the best resource for searching the object library outside of hassling the pd-list. i still don't think pdpedia has filled those shoes, which were in fact very simple and tidy, but i digress.. thanks for your encouraging response! dmotd On Thursday 09 April 2009 18:24:13 marius schebella wrote: > hi dmotd, > > your post is great, it reminded me of all the ideas I had before > starting pdpedia. > my main motivation for working on a pd(pedia) object > database/documentation was to help users (including myself) find > the right object for their purpose and help developers by > preventing redundancy in writing new objects. -- I also got stuck > by the limitations of mediawiki. > some of the things, for example that I'd like to see: > make heavy use of *data mining* in existing pd patches: It should > be possible to know, how often an object is used, and how often > it is connected to which other object and which objects share the > same window. it should even be possible to tell the search engi
[PD] new arduino mega
HI everybody... the new arduino mega is here, but i think the ide program and the pduino object must update...Hans is possible or is possible change parameteres in firmata and pduino??? well... just a questions... Have a nice day friends Check the blog... the firts video in in Spanish and the secon English Thanks a lot Cheers from Chile José Luis -- http://arselectronicachile.blogspot.com/ www.myspace.com/santorcuato ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
2009/4/9 Frank Barknecht : > Hallo, > dmotd hat gesagt: // dmotd wrote: > >> i am not at all convinced that pdpedia/mediawiki serves as a good >> method for object reference. it is difficult to maintain (a lot of >> manual copy and paste), its search/sort functionality is limited, >> the up/down stream api is severely lacking and most of all it is >> difficult to integrate it into a pd environment (outside of simple >> pddp links which are usually inside the object reference anyhow). > > I believe, reference documentation belongs into the code and additional > display > methods should be generated from that. hi frank, please be more elaborate. are you distinguishing between reference and documentation? is "reference documentation" the help patches or some other kind of object reference. are you talking about code comments? in help patches? or in the C code? I think that the purpose of documentation is to teach/explain how to use objects? reference might be something slightly different. the problem imho is that there is no basis right now on which an automatic documentation generation could build on. I also think that autogeneration would be extremely helpful, but... who of the vanilla/external-developers will reliably stick to any rules? since developers are bad documentators but you still propose that code should be the source to generate documentation, how do you think people (who would like to do some documentation) should contribute? directly to the source code? how do you envision that users will search for objects? where do you think information like tags, similar objects, example patches should come from? marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
Hallo, dmotd hat gesagt: // dmotd wrote: > i am not at all convinced that pdpedia/mediawiki serves as a good > method for object reference. it is difficult to maintain (a lot of > manual copy and paste), its search/sort functionality is limited, > the up/down stream api is severely lacking and most of all it is > difficult to integrate it into a pd environment (outside of simple > pddp links which are usually inside the object reference anyhow). I believe, reference documentation belongs into the code and additional display methods should be generated from that. What's currently useful in pdpedia mostly was generated by a script, but a year or so ago and it may already be outdated or referring to objects not available anymore (i.e. http://wiki.puredata.info/en/mapping/degrees0x2d0x3emapping) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] timing issues in Windows Vista
Weird, weird weird, but solved it seems. Roman Haefeli escribió: i think, the samplingrate, that pd thinks it is using and the one that it is actually using, are differnt. try an [osc~ 440], it will sound like a d. First I tried by using -noaudio and the timing issue disappeared, suggesting the diagnostic made by Roman was correct. Then I switched to ASIO mode and the timing issue disappeared. I don't have absolute ear nor a diapason (nor any tuned musical instrument at home), but the tone in "test Audio and Midi" sounds exactly equal to the one in my older computer with XP which I know to be a reliable reference. Also, with ASIO I was able to use the default 70ms latency settings without glitches, while in default MMIO mode I had to use 200ms or so. Now the WEIRD WEIRD thing is that I switched back to MMIO mode, and now it still works fine, the timing is still correct. I never made any "save all setting", so I restarted the computer (Windows Vista, the one previously presenting the issue), I opened PD with its default settings (MMIO) and opened the time test patch, changed only the latency setting to 200 in order to avoid glitches, and everything still works fine, with correct timing and correct pitch. Even changing sampling rate to different values, everything works as expected. In MMIO mode. And of course if I switch to ASIO it also works fine (and with lower latency). I assure you that when I wrote I had tested the issue more than once and also after restarting the computer at least once. I can only guess that the simultaneous use of some other application accessing the soundcard (IExplorer through Flash or Silverlight plugins, quicktime player, winamp, etc) may have messed something up, and probably even if I tested more than once even restarting the computer, I always had one of such applications running (often I listen to music or see stream TV programs and then leave winamp or the browser open and minimized and idle without closing it - bad habits). So the problem seems gone and seems to be related to some sound card driver mess, possibly not related to any PD bug. Thank Roman for the suggestions. Bye m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] timing issues in Windows Vista
Weird, weird weird, but solved it seems. Roman Haefeli escribió: i think, the samplingrate, that pd thinks it is using and the one that it is actually using, are differnt. try an [osc~ 440], it will sound like a d. First I tried by using -noaudio and the timing issue disappeared, suggesting the diagnostic made by Roman was correct. Then I switched to ASIO mode and the timing issue disappeared. I don't have absolute ear nor a diapason (nor any tuned musical instrument at home), but the tone in "test Audio and Midi" sounds exactly equal to the one in my older computer with XP which I know to be a reliable reference. Also, with ASIO I was able to use the default 70ms latency settings without glitches, while in default MMIO mode I had to use 200ms or so. Now the WEIRD WEIRD thing is that I switched back to MMIO mode, and now it still works fine, the timing is still correct. I never made any "save all setting", so I restarted the computer (Windows Vista, the one previously presenting the issue), I opened PD with its default settings (MMIO) and opened the time test patch, changed only the latency setting to 200 in order to avoid glitches, and everything still works fine, with correct timing and correct pitch. Even changing sampling rate to different values, everything works as expected. In MMIO mode. And of course if I switch to ASIO it also works fine (and with lower latency). I assure you that when I wrote I had tested the issue more than once and also after restarting the computer at least once. I can only guess that the simultaneous use of some other application accessing the soundcard (IExplorer through Flash or Silverlight plugins, quicktime player, winamp, etc) may have messed something up, and probably even if I tested more than once even restarting the computer, I always had one of such applications running (often I listen to music or see stream TV programs and then leave winamp or the browser open and minimized and idle without closing it - bad habits). So the problem seems gone and seems to be related to some sound card driver mess, possibly not related to any PD bug. Thank Roman for the suggestions. Bye m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] embedded preferences...
hi all. i was wondering what the status of "embedded preferences" (that is: using a local preference file that is attached with a certain Pd-application rather than the global preferences valid for all Pd's on the system) for all platforms and the various tastes of Pd was. i know that you can embed a preference file in an osx-bundle in Pd-extended (at least since 0.40), and iirc this embedding has been accepted into Pd-vanilla as well (since version ?) i seem to remember that a similar mechanism exists on linux. i cannot remember anything about w32 (which might be more complicated, given that with w32 we are using the registry rather than a file that ships with Pd) so my question is: - is embedding preferences supported on all platforms? - is embedding preferences supported on both Pd-vanilla and Pd-extended? - what is the minimum version of Pd i need to acquire the usufruct (with regard to taste) fgamdsr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
cyrille henry wrote: Hans-Christoph Steiner a écrit : ... If there is good code out there, I want to use it, not reinvent it. having a complex abstraction to replace this : loadbang $1 moses 0 shouldn't that be [select 0] rather than [moses 0] ? mfgasd.r IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
yes, i agree that pdpedia/mediawiki has its place, however it is another resource for documentation that is currently competing with the plone wiki reference at puredata.org. This means that we have two distinct references, both apparently supported by the 'pd community', and frankly this just creates another point of confusion and an area where information can quickly become derelict. really we should be attempting to eliminate redundancy where possible. i am not at all convinced that pdpedia/mediawiki serves as a good method for object reference. it is difficult to maintain (a lot of manual copy and paste), its search/sort functionality is limited, the up/down stream api is severely lacking and most of all it is difficult to integrate it into a pd environment (outside of simple pddp links which are usually inside the object reference anyhow). so yes, pdpedia is convenient at this stage, but i am more interested in building an environment that will engage better with pd itself, and this is basically what i am proposing. cheers, dmotd On Thursday 09 April 2009 12:59:09 Hans-Christoph Steiner wrote: > I don't think that pdpedia is a replacement or substitute for > interactive help patches. But mediawiki is a great tool for > getting lots of bits of information from a lot of people. So I > think that pdpedia could be used as a place to orgnanize content, > like reference info, links to related algorithms, links to > related video tutorials, etc. That material could then be > filtering into the help patches themselves. > > A pd-help file wiki would be great, but until then, I think > pdpedia could be useful. > > .hc > > On Apr 8, 2009, at 10:35 PM, dmotd wrote: > > hi folks, > > > > i am somewhat interested in investing some time in pdpedia, but > > i have a few concerns with mediawiki as a container for pd > > related data. > > > > obviously mediawiki is an excellent versioning platform and has > > a strong following for many technical wiki's in the open-source > > community. i think its an excellent format for plain text > > information, which takes the form of tutorials/howto/guide, but > > as an object reference it has a limited scope. > > > > this is especially the case when attempting to pull that > > information into another format (ie.. not html). anything > > pulled off the server using the api needs to be parsed to be > > made useful in another context, and in many cases reparsed to > > pick out the > > meta-references, and this is without getting to the content > > which is often categorised in an entirely different format. > > > > i have previously invested a fair chunk of time in refencing > > objects in a sql database, while my work was not designed with > > versioning in mind, it was designed to be utilised by pd (dd > > was the projected environment) or pd libs internally, or in > > other formats like a postscript reference or generating pddp > > formatted helpfiles. i have recently started picking up the > > pieces of this project (which i had ceased with the initial > > announcement of pdpedia). > > > > anyhow, what i am beginning to see a need for is an > > infrastructure like mediawiki which stores pd files rather than > > plain-text. think of it like a categorised + tagged svn. this > > would be a place where people can upload files relating to pd > > use, examples of usage, methods of interfacing and anything > > else that gets passed around on this mailing list. keeping with > > the same wiki format of edits by anyone, and versioning each > > subsequent edit. then in a similar method to mediawiki api > > calls, pd internally could request a list of articles > > (pd-patches) and dynamically retrieve requested articles from > > the pdwiki. thus making the system much more usable within the > > pd environment. > > > > i think the benefit of this would be quite obvious to pd-users, > > as it has been stated many times by numerous people that a > > plain text wiki reference doesn't really make much sense > > without the interactive characteristics of an actual patch. > > > > this is something i would happily put energies into > > development, and in many ways have already started. i will > > likely end up building something that works in this way anyway, > > so please throw in suggestions, before i get carried away ;) > > > > ciao, > > > > dmotd > > > > On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote: > >> There are lots of good ideas worth trying. We've talked about > >> it a lot, we just need someone to take charge of it. I am > >> just too overloaded to handle pdpedia on top of everything > >> else. Who wants to own it? > >> > >> .hc > >> > >> On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote: > It would be good to have > standards on how articles should be formatted and what kind > of information should be presented. > >>> > >>> yes I agree. At the origin in 2006..., I have suggested to > >>> some french PDers the following fe
Re: [PD] auto 1 loops pix_film (and pix_movie?)
Exactly. Your example is even better than my description... it could be suitable for the FLOSS manual in my opinion. best On Wed, Apr 8, 2009 at 6:37 PM, Jack wrote: > Here a small exemple.++ > > Jack > > > Le 8 avr. 09 à 16:52, Marco Donnarumma a écrit : > > Yes, Connect the second outlet of [pix_film] to [unpack]. > Then the first outlet of [unpack] will give you the total amount of frames > of the video you load. > So you can connect the first outlet of [unpack] to the last inlet of > [counter]. This will set the maximum value to reach for [counter]. > I use [counter] to play each frame of the video and i send the scratch > values in its third inlet. > > this is how i do it... but as Derek were suggesting there is the [mod] > object too.. Derek how do you use it? > just for curiosity... > thanks.. > > best > > > > > On Wed, Apr 8, 2009 at 3:11 PM, Jack wrote: > >> >> Le 8 avr. 09 à 10:34, Marco Donnarumma a écrit : >> >> Hey.. >> thanks Derek, yes i've already done what you're saying for my project >> C::NTR::L and i have a simple process which give me dynamically the total >> frames for each video you load. >> >> With the 2nd output of [pix_film] for exemple ? ;) >> ++ >> >> Jack >> >> >> I was asking just to know the truth about it :) >> Since i'm using this process a lot i could create a specific example about >> this for FLOSS manual. I have this exact process ready in my patches. >> ATM i'm terribly busy, but i'll keep it in mind and contribute asap. >> best.. >> >> >> Marco >> >> >> >>> Hi Marco, >>> >>> This has been normal behavior as long as I have been aware of it. That >>> doesn't mean that it's not a bug, however ;-) >>> >>> If you want looping + scrubbing, a better way would be to build a >>> counter with a [mod] object set to the total number of frames in your >>> clip, that way you could change the payback speed of the clip and (with >>> some adjustments to the counter) skip around in the frames as well as go >>> backwards, etc etc. (Nice topic for a FLOSS Manuals tutorial, eh Marius?) >>> >>> best! >>> Derek >>> >>> Marco Donnarumma wrote: >>> > If i send a [auto 1( to [pix_film] i'm not able anymore to scratch the >>> > movie sending values to its cold inlet. >>> > Is this bug connected with the bug you talk about or a normal function >>> > of the obj.? >>> > >>> > besides i noticed pix_movie doens't have this behaviour but is crashing >>> > on most of the MAC OS i tried with. is this another known issue? >>> >>> >>> -- >>> ::: derek holzer ::: http://blog.myspace.com/macumbista ::: >>> http://www.vimeo.com/macumbista ::: >>> ---Oblique Strategy # 37: >>> "Convert a melodic element into a rhythmic element" >>> >>> >>> >>> -- >>> >>> Message: 7 >>> Date: Tue, 07 Apr 2009 18:22:36 +0200 >>> From: marius schebella >>> Subject: Re: [PD] auto 1 loops pix_film (and pix_movie?) >>> To: Derek Holzer >>> Cc: pd-list@iem.at >>> Message-ID: <49db7dcc.90...@gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Derek Holzer wrote: >>> > Hi Marco, >>> > >>> > This has been normal behavior as long as I have been aware of it. That >>> > doesn't mean that it's not a bug, however ;-) >>> > >>> > If you want looping + scrubbing, a better way would be to build a >>> > counter with a [mod] object set to the total number of frames in your >>> > clip, that way you could change the payback speed of the clip and (with >>> > some adjustments to the counter) skip around in the frames as well as >>> go >>> > backwards, etc etc. (Nice topic for a FLOSS Manuals tutorial, eh >>> Marius?) >>> > >>> >>> something like that is already there, but not as a separate example >>> (yet...) >>> marius. >>> >> >> >> -- >> Marco Donnarumma aka The !S.A.D! >> >> >> >> Multimedia Artist, Live Performer >> Roma, IT >> >> LAB: http://www.thesaddj.com | http://www.flxer.net >> >> EVENT: http://www.liveperformersmeeting.net >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> > > > -- > Marco Donnarumma aka The !S.A.D! > > > > Multimedia Artist, Live Performer > Roma, IT > > LAB: http://www.thesaddj.com | http://www.flxer.net > > EVENT: http://www.liveperformersmeeting.net > > > > -- Marco Donnarumma aka The !S.A.D! Multimedia Artist, Live Performer Roma, IT LAB: http://www.thesaddj.com | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pdpedia and random generation
hi dmotd, your post is great, it reminded me of all the ideas I had before starting pdpedia. my main motivation for working on a pd(pedia) object database/documentation was to help users (including myself) find the right object for their purpose and help developers by preventing redundancy in writing new objects. -- I also got stuck by the limitations of mediawiki. some of the things, for example that I'd like to see: make heavy use of *data mining* in existing pd patches: It should be possible to know, how often an object is used, and how often it is connected to which other object and which objects share the same window. it should even be possible to tell the search engine where in the patch (x/z area) an object was placed. I want to search for objects related to key words, tags, maybe categories (although a fixed structure is definitely a bad idea), libraries, similar objects, sort by all kinds of means (date, popularity, operating system). On top of this pd-base there should be a place like *youtube*, where you can post your own patches, have favorites, have a list of favorite objects. I know that it is not possible (yet) to play a pd patch within a browser, but I am sure someone will come up with a firefox plugin anytime soon. I also think that people should be able to comment on objects, or rate them, or have rss feeds if someone posts a new patch that contains a certain object or is related to a certain topic. and your point about exchanging data formats is extremely important, too. I know that mediawiki has a method to import/export - in theory, but this can by no means compared to a real query api. of course, maintaining all that information is a hell of a work. that was the point where the wiki idea came into place (a lot of people contributing). but after a year of pdpedia I still don't see this taking off, which makes me want to try out something new. btw is there any literature or real world examples of how other groups/open source communities deal with the *lack of physical/financial resources*? marius. 2009/4/9 dmotd : > hi folks, > > i am somewhat interested in investing some time in pdpedia, but i > have a few concerns with mediawiki as a container for pd related > data. > > obviously mediawiki is an excellent versioning platform and has a > strong following for many technical wiki's in the open-source > community. i think its an excellent format for plain text > information, which takes the form of tutorials/howto/guide, but as > an object reference it has a limited scope. > > this is especially the case when attempting to pull that information > into another format (ie.. not html). anything pulled off the server > using the api needs to be parsed to be made useful in another > context, and in many cases reparsed to pick out the > meta-references, and this is without getting to the content which > is often categorised in an entirely different format. > > i have previously invested a fair chunk of time in refencing objects > in a sql database, while my work was not designed with versioning > in mind, it was designed to be utilised by pd (dd was the projected > environment) or pd libs internally, or in other formats like a > postscript reference or generating pddp formatted helpfiles. i have > recently started picking up the pieces of this project (which i had > ceased with the initial announcement of pdpedia). > > anyhow, what i am beginning to see a need for is an infrastructure > like mediawiki which stores pd files rather than plain-text. think > of it like a categorised + tagged svn. this would be a place where > people can upload files relating to pd use, examples of usage, > methods of interfacing and anything else that gets passed around on > this mailing list. keeping with the same wiki format of edits by > anyone, and versioning each subsequent edit. then in a similar > method to mediawiki api calls, pd internally could request a list > of articles (pd-patches) and dynamically retrieve requested > articles from the pdwiki. thus making the system much more usable > within the pd environment. > > i think the benefit of this would be quite obvious to pd-users, as > it has been stated many times by numerous people that a plain text > wiki reference doesn't really make much sense without the > interactive characteristics of an actual patch. > > this is something i would happily put energies into development, and > in many ways have already started. i will likely end up building > something that works in this way anyway, so please throw in > suggestions, before i get carried away ;) > > ciao, > > dmotd > > > > On Thursday 09 April 2009 07:25:06 Hans-Christoph Steiner wrote: >> There are lots of good ideas worth trying. We've talked about it >> a lot, we just need someone to take charge of it. I am just too >> overloaded to handle pdpedia on top of everything else. Who >> wants to own it? >> >> .hc >> >> On Apr 1, 2009, at 11:21 AM, Jean-Noël Montagné wrote: >> >> It would be good
