Re: [PD] NetPd status
Hi Quim On Tue, 2012-03-13 at 12:27 +0100, Quim Llimona wrote: > Hi all, > > The Barcelona Laptop Orchestra has been working with some network > abstractions built specifically per piece (chats, OSC sync and so). I was > thinking on making a whole, reusable framework, but then I read about the > NetPd system... I'd like to develop stuff from it (some GUI abstractions, > log systems, etc), but it says it's under a transition and so. Does anybody > know the current status of the project? Is it usable now, or should I use > the old system? netpd is currently a one-man show. This means, it's only me working on it and occasionally playing with it. The new OSC based version is much more mature than the original framework ever was. The old netpd is not maintained anymore and I wouldn't use it, though it still seems to run OK with today's version of Pd[-extended]. I'd say the new netpd framework is in a beta stage now. I haven't touched the server for quite a while (it seems robust) and also worked on the client-side framework stuff only occasionally, mainly when smallish issues were found during development of custom made netpd-patches / instruments. In recent weeks, I actually spent most time on importing old netpd-patches to the new framework or rewriting them from scratch. The most important ones are already done. The one big chunk still missing is a proper documentation and also eventually making a release. I don't follow a particular schedule, though. Explained in only a few words, the main goal of the framework is to ensure instrument/patch synchronisation (every client has the same set of of custom made patches loaded at any time) and state synchronization (the state of a certain patch is the same on every client at any time). Of course, you can pick only the features you're interested to. For instance, you could use it only for passing OSC messages around between clients. I tried to make the framework modular, so it might well be that you find something for your needs, but to tell you more about it, I'd need to know more precisely what you're trying to achieve. I encourage you to try out the new netpd yourself. To get a running setup, do this in a terminal: $ git clone git://github.com/reduzent/netpd2.git $ git clone git://github.com/reduzent/netpd2-patches.git $ cd netpd2 $ rm -rf abs/ patches/ $ ln -s ../netpd2-patches/patches/ $ ln -s ../netpd2-patches/abs/ This will give you the framework itself plus a set of patches/instruments. To run it, open 'netpd2/chat.pd' in your 0.43 version of Pd or Pd-extended. The following external libraries are used: * iemnet * osc * mrpeach ([slipdec] and [slipenc]) * zexy Have fun (or report back)! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vline~ precision, or sequentially segmented playback of a buffer
> The offset of [tabread4~] was there to avoid any reading errors when the > index points get too high (the whole sample is almost 7m long). So there's > not option for this, but to use only the right entry? Seems like you should stick with your original approach using the right inlet for good indexing resolution, and work in a [block~ 1] subpatch to force the inlet to update every sample. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] When the Going Gets Weird, the Weird Turn Pro [was] Anonymity.
Ouch - Dominic that ain't nice. Patrick you're nitpicking think/suspect are fairly interchangeable and maybe this is a language/culture thing but it didn't seem that humorous to me. Very admirable and straight apology though (I don't do sarcasm/irony if I can help it). Well, there he goes then - 'who was that dark stranger'. Never really understand what the hell went on between Sevy/Matju, something serious I hope for all the years of wrangling. I put it down to them both having spent too much time coding to have worked on people skills tbh. I think they're both very good at what they do. It should be said that there was a fairly nasty putsch with Degoyan last year but it's noticeable that people are still wanting to make use of his software, thus giving him more opportunity to vent some spleen in the process. And wherever he got the code from is in some sense irrelevant - he spotted things that people would want to use and did it early. It was always good to have someone with that (possibly cliched) radicalism in our midst I thought - a group consciousness extension. I also think some of his points may be hitting home-truths, there is a certain decadence to a lot of our conversations recently - perhaps fiddling while Rome burns? You know I've been meaning to rename one of these posts with "when the going gets weird, the weird turn pro" and maybe now's the time. As for myself, the only comment on this list that feels relevant (and he may not have writing about me anyway) was Jonathan's mention of ruining a good point with bad etiquette (Alex McLean's post on 80c in response to my freakout being a corker). Personally I'm off for some Maoist/Marxist/Leninist purging. Sorry, I meant coding, Julian On 13 March 2012 18:42, Dominic Pflaum wrote: > > > On Tue, Mar 13, 2012 at 5:12 PM, Pagano, Patrick < > p...@digitalworlds.ufl.edu> wrote: > >> Sevy, >> >> 1.) I never said I THINK it is you, I said I SUSPECT it was you, so no >> slander... >> 2.) Also, I'm sorry if I offended you, I THOUGHT everyone was actually >> being humorous. >> >> It was not my intention to hurt your feelings and for this I apologize. >> >> Sincerely, >> >> Patrick >> >> >> On 3/13/12 12:43 PM, "ydego...@gmail.com" wrote: >> >> >ola, >> > >> >ola, >> > >> >conclusion is : >> > >> >although i've been slandered _again_ by people that >> >will never apologize, i don't mind, >> >this only shows the stupidity of the author >> >of such mail as : >> > >> >'i think it is sevy' >> > >> >i'm just thinking i'm right to have left this community, >> >and that's fine because i don't use pd anyway anymore, >> >it sounds too poor and is way too limited >> >for a real good interactive application. >> > >> >i'm not the only one, many people switched to super-collider for sound, >> >and open frameworks for interactivity, >> >there's no more pd community in bcn, i must say. >> > >> >that's it, >> >so please that nobody ask me any help, >> >support for people that treated me like that >> >is discontinued ... >> > >> >that's all, >> >sevy >> > >> > >> >___ >> >Pd-list@iem.at mailing list >> >UNSUBSCRIBE and account-management -> >> >http://lists.puredata.info/listinfo/pd-list >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vline~ precision, or sequentially segmented playback of a buffer
Hi Andy, Joao, if the jumps are always (theoretically zero) going to be very small (no backjumps of a whole segment) then let's suggest a quick and practical fix and ignore the whole issue of sample accuracy in the control system. I take it you only need this to sound good enough, not be sample accurate: Place a [lop~ 1000] after the [vline~] This will remove any sudden little jumps and smooth the playback at segment boundaries. Might be good enough for rock n roll. unfortunately, there are places where part of the table is played by another player (you'll see the gaps in the text file). But also, unfortunately the lop~ doesn't change the result at all, I think. At least I couldn't hear it, also not by changing the value to something bigger. The clicks in the direction corners are still there. João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vline~ precision, or sequentially segmented playback of a buffer
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file. This also is the reason for the 181 msec clicks I get. Replacing the whole [list-sub] construction with a simple [$1, $2 $3( between [textfile] and [vline~] gives a nice and clean sound, except at the turnaround points where clicks are expected anyway. The offset-index of [tabread4~] is a message inlet that is not timing accurate, [tabread4~] will use the value from here at a different time than [vline~] uses its own copy of the value, leading to clicks. Very strange. In the computer I am now, I do hear the regular clicks, but I didn't heard them before. The offset of [tabread4~] was there to avoid any reading errors when the index points get too high (the whole sample is almost 7m long). So there's not option for this, but to use only the right entry? I was watching the recorded result of the test patch, and the clicks in the direction change happen, even though the recorded wave is simmetrical. I though that the result would be a continous wave with no clicks, but where did I go wrong? I guess the corner in the wave, even being symmetrical, always produces a click, right? João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Anonymity.
On Tue, Mar 13, 2012 at 5:12 PM, Pagano, Patrick wrote: > Sevy, > > 1.) I never said I THINK it is you, I said I SUSPECT it was you, so no > slander... > 2.) Also, I'm sorry if I offended you, I THOUGHT everyone was actually > being humorous. > > It was not my intention to hurt your feelings and for this I apologize. > > Sincerely, > > Patrick > > > On 3/13/12 12:43 PM, "ydego...@gmail.com" wrote: > > >ola, > > > >ola, > > > >conclusion is : > > > >although i've been slandered _again_ by people that > >will never apologize, i don't mind, > >this only shows the stupidity of the author > >of such mail as : > > > >'i think it is sevy' > > > >i'm just thinking i'm right to have left this community, > >and that's fine because i don't use pd anyway anymore, > >it sounds too poor and is way too limited > >for a real good interactive application. > > > >i'm not the only one, many people switched to super-collider for sound, > >and open frameworks for interactivity, > >there's no more pd community in bcn, i must say. > > > >that's it, > >so please that nobody ask me any help, > >support for people that treated me like that > >is discontinued ... > > > >that's all, > >sevy > > > > > >___ > >Pd-list@iem.at mailing list > >UNSUBSCRIBE and account-management -> > >http://lists.puredata.info/listinfo/pd-list > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > <>___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Kinect mappings
Hello I am collaborating with a programmer who has developed a kinect streamer with windows SDK that sends data over udp. I am soliciting some ideas on WHAT to do with the data stream. We are thinking movies/models and midi, but I would love to hear some ideas regarding what to do with the data Cheers~ pp OSCroute_kinect4.pd Description: OSCroute_kinect4.pd ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Anonymity.
Sevy, 1.) I never said I THINK it is you, I said I SUSPECT it was you, so no slander... 2.) Also, I'm sorry if I offended you, I THOUGHT everyone was actually being humorous. It was not my intention to hurt your feelings and for this I apologize. Sincerely, Patrick On 3/13/12 12:43 PM, "ydego...@gmail.com" wrote: >ola, > >ola, > >conclusion is : > >although i've been slandered _again_ by people that >will never apologize, i don't mind, >this only shows the stupidity of the author >of such mail as : > >'i think it is sevy' > >i'm just thinking i'm right to have left this community, >and that's fine because i don't use pd anyway anymore, >it sounds too poor and is way too limited >for a real good interactive application. > >i'm not the only one, many people switched to super-collider for sound, >and open frameworks for interactivity, >there's no more pd community in bcn, i must say. > >that's it, >so please that nobody ask me any help, >support for people that treated me like that >is discontinued ... > >that's all, >sevy > > >___ >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] mrpeach routeOSC behaves differently then its previous release?
Well it was simple enough to implement. The newest [routeOSC] in svn should handle lists and messages the same, even though you shouldn't be using lists ;) Also any non-OSC messages will be sent through the rightmost outlet. Martin On 2012-03-13 12:14, yvan volochine wrote: On 03/13/2012 07:12 AM, Frank Barknecht wrote: Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm. As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity. IMHO it's really a user mistake to send [list /what/ever 123( to [routeOSC]. this recent change looks more like a (accidental!) bugfix than a regression to me (whether it breaks old code or not.. breaking faulty code should not count, oder? =). cheers, y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Anonymity.
ola, ola, conclusion is : although i've been slandered _again_ by people that will never apologize, i don't mind, this only shows the stupidity of the author of such mail as : 'i think it is sevy' i'm just thinking i'm right to have left this community, and that's fine because i don't use pd anyway anymore, it sounds too poor and is way too limited for a real good interactive application. i'm not the only one, many people switched to super-collider for sound, and open frameworks for interactivity, there's no more pd community in bcn, i must say. that's it, so please that nobody ask me any help, support for people that treated me like that is discontinued ... that's all, sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
On 03/13/2012 07:12 AM, Frank Barknecht wrote: Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm. As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity. IMHO it's really a user mistake to send [list /what/ever 123( to [routeOSC]. this recent change looks more like a (accidental!) bugfix than a regression to me (whether it breaks old code or not.. breaking faulty code should not count, oder? =). cheers, y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
Hi Roman, On Tue, Mar 13, 2012 at 12:19:59PM +0100, Roman Haefeli wrote: > Though I lack to see the necessity to change [routeOSC]'s current > behaviour, I agree that it most likely wouldn't cause any harm. As I understand it, this topic only came up because apparently the behaviour has been changed in the newest release to not allow list-messages containing OSC-messages as first item anymore, breaking some old patches without any urgent necessity. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] NetPd status
Hi all, The Barcelona Laptop Orchestra has been working with some network abstractions built specifically per piece (chats, OSC sync and so). I was thinking on making a whole, reusable framework, but then I read about the NetPd system... I'd like to develop stuff from it (some GUI abstractions, log systems, etc), but it says it's under a transition and so. Does anybody know the current status of the project? Is it usable now, or should I use the old system? Cheers, Quim ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
Hi Frank Though I lack to see the necessity to change [routeOSC]'s current behaviour, I agree that it most likely wouldn't cause any harm. Roman On Tue, 2012-03-13 at 11:17 +0100, Frank Barknecht wrote: > Hi, > > On Tue, Mar 13, 2012 at 10:02:01AM +0100, Roman Haefeli wrote: > > You're not convinced of what now? > > Sorry for the unclarity: I'm not convinced of the recent change in [routeOSC], > I think, it would work fine accepting list-messages as well as proper > OSC-meta-messages. > > > The proposal is actually what you describe above. Currently it _does_ make a > > separation between 'list' selector and 'OSC path' selector (it disregards > > messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of > > the proposal to change [routeOSC]s behaviour to make it also messages with > > the 'list' selector'? > > Yes. > > > Hans proposed to generally get rid of the separation between 'list' > > selector and 'any' selector messages in all parts of Pd. > > That's what I'm not convinced of: When designing a new language, one may > consider a different approach. But I don't see a need to change this system in > Pd now, it works fine in general. > > > undecided whether this is a good idea, but if it would be done, I'd > > consider it a bad approach to do it in every (external and internal) > > class separately. Rather should Pd's message system be changed. > > Well, the whole list-/any-/float-/...-messages *are* Pd's message system. It's > a very flexible system, that allows differentiating between all kinds of > messages. In the end it's up to the author of a patch/external/abstraction to > decide which distinctions should be used. Not everything that is allowed has > to > be done all the time. > > In the [list]-objects (minus trim) the distinction between "list"-messages and > "meta"-messages is not necessary, because lists are all these objects deal > with. So it makes sense that these objects treat meta-messages like > list-messages. > > That's very different from for example [pipe s s 1000] which will delay a > [list > x y( or a [symbol S( for one second, but can still be flushed with a "flush" > meta-message. > > > In this particular case, [routeOSC]'s behaviour is consistent with its > > brothers and sisters, since [unpackOSC] also outputs only messages with > > an OSC path as selector. > > So what? [routeOSC] will continue to work fine with what it gets from > [unpackOSC], but additionally users constructing their own OSC-messages with > [list]-operations could skip the final [list trim]. > > > Also for the documentation it's much more concise to state 'the selector of > > the incoming message is considered the OSC path' than 'the selector of the > > incoming messages is considered the OSC path, unless the selector is "list" > > where the first element of the message is considered the OSC path'. > > "The first element in the incoming message is considered the OSC path." :) No > mentioning of selectors, list-message, meta-messages needed to document it > here, unless one is a language lawyer. > > Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd as realtime priority process under WinXP
Hi David and list, AFAIK real-time priority processes are available on G/Linux with special kernel loaded (low-latency kernels /rt-kernels )... Not sure if is possible it in other OSs Another point is that youll need a very powerful computer to be able to flow those processes at low latency, otherwise low-latency kernels are working even worst than the regular ones. (this last comment is obvious, but i remind) salut xà! 2012/3/12 David Schaffer : > Hi there, > > I'm trying to start Pd with realtime priority using a .bat file and the > "/realtime" parameter. pd starts as expected but as "high" priority > process. I know my command syntax is right because I tried it on other > software and they all ran as "realtime" processes. Is there an internal pd > setting that overrides this and, if there is, how can I change it? > > Thank you guys very much for your help. > > D.S > > > http://www.flickr.com/photos/schafferdavid/ > > http://audioblog.arteradio.com/David_Schaffer/ > > > ___ > 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-announce] Scholarships for Music Technology MA/MSc program at the University of Limerick
Hello List, Some details regarding funding opportunities for the MA/MSc in Music Technology at University of Limerick follow.Please feel free to distribute widely. Kind regards Nick Master's in Music Technology Funding Opportunities The Department of Computer Science and Information Systems has made available two fees-only scholarships for EU students on the MA/MSc Music Technology program at the University of Limerick. In addition to this a number of generous scholarships are available to full-time non-EU postgraduate students through the Faculty of Science and Engineering. Full details are available at http://www.dmarc.ie/education/music_technology_masters/scholarships-funding/ The Masters in Music Technology is funded through the Graduate Skills Conversion Programme. Fees for EU students for the the academic year 2012 -2013 will be approximately €3000. __ Master's in Music Technology Delivered at DMARC (Digital Media & Arts Research Centre) the Master’s Degree in Music Technology is a one year full-time course which exposes students to a broad range of music technology related disciplines. The course is aimed at candidates who wish to combine technological competence with artistic endeavor. A key element of the course is its focus on both the technical and creative aspects of sound art. To this end, equal emphasis is placed on the development of compositional and critical approaches to music technology, as well as to the development of technical skills including audio production and programming. Delivered through a combination of taught modules and directed research projects the course culminates in the development of a dissertation and portfolio which provides an opportunity for the student to focus in detail on a specialist area under the supervision of a member of staff. Previous dissertation and portfolio topics have included; live electronic performance, composition for mixed media, interactive audio, sound installation, DSP programming, audio plugin development and perceptual studies. In addition to the many facilities at DMARC, students have exclusive access to a music computer lab and to the postgraduate studio suites. Further details about the course are available at http://www.dmarc.ie/education/music_technology_masters/ Nicholas Ward Course Director - MA/MSc in Music Technology DMARC (Digital Media & Arts Research Centre) Dept. of Computer Science and Information Systems University of Limerick Limerick Ireland T: +353 (0) 61 234246 W: www.dmarc.ie E: ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] problem with 43.1 on os lion
problem solved. i had 42.5 in the same directory and that must have
caused some confusion with the paths for some reason. thrashing it
fixed the issue.
thanks for pointing me in the right direction!
ralf
On 12.03.2012, at 18:16, Ralf Blagau wrote:
> hello,
>
> i'm having a problem with 43.1 on os lion. i am running quite a big patch
> with some guy elements that runs flawless on 42.5. but every time i click
> into the guy on 43.1 i get an application error saying:
> Error: invalid command name "pd"
>
> in the details it says:
>
> invalid command name "pd"
> invalid command name "pd"
> while executing
> "pd [concat #hammergui _vised .x472810.c 1 \;]"
> invoked from within
> "if {[hammergui_ispatcher .x472810.c]} {pd [concat #hammergui _vised
> .x472810.c 1 \;]}"
> (command bound to event)
>
> or
>
> invalid command name "pd"
> invalid command name "pd"
> while executing
> "pd [concat #hammergui _up 0 \;]"
> (command bound to event)
>
> this happens every time i click on anything, so i can't move any faders or
> anything. i guess i should post this on the bug tracker, but i don't really
> know how it works.
> apart from that 43.1 looks like an amazing release and i'm looking forward to
> get it to work.
>
> thanks,
> ralf
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
Hi, On Tue, Mar 13, 2012 at 10:02:01AM +0100, Roman Haefeli wrote: > You're not convinced of what now? Sorry for the unclarity: I'm not convinced of the recent change in [routeOSC], I think, it would work fine accepting list-messages as well as proper OSC-meta-messages. > The proposal is actually what you describe above. Currently it _does_ make a > separation between 'list' selector and 'OSC path' selector (it disregards > messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of > the proposal to change [routeOSC]s behaviour to make it also messages with > the 'list' selector'? Yes. > Hans proposed to generally get rid of the separation between 'list' > selector and 'any' selector messages in all parts of Pd. That's what I'm not convinced of: When designing a new language, one may consider a different approach. But I don't see a need to change this system in Pd now, it works fine in general. > undecided whether this is a good idea, but if it would be done, I'd > consider it a bad approach to do it in every (external and internal) > class separately. Rather should Pd's message system be changed. Well, the whole list-/any-/float-/...-messages *are* Pd's message system. It's a very flexible system, that allows differentiating between all kinds of messages. In the end it's up to the author of a patch/external/abstraction to decide which distinctions should be used. Not everything that is allowed has to be done all the time. In the [list]-objects (minus trim) the distinction between "list"-messages and "meta"-messages is not necessary, because lists are all these objects deal with. So it makes sense that these objects treat meta-messages like list-messages. That's very different from for example [pipe s s 1000] which will delay a [list x y( or a [symbol S( for one second, but can still be flushed with a "flush" meta-message. > In this particular case, [routeOSC]'s behaviour is consistent with its > brothers and sisters, since [unpackOSC] also outputs only messages with > an OSC path as selector. So what? [routeOSC] will continue to work fine with what it gets from [unpackOSC], but additionally users constructing their own OSC-messages with [list]-operations could skip the final [list trim]. > Also for the documentation it's much more concise to state 'the selector of > the incoming message is considered the OSC path' than 'the selector of the > incoming messages is considered the OSC path, unless the selector is "list" > where the first element of the message is considered the OSC path'. "The first element in the incoming message is considered the OSC path." :) No mentioning of selectors, list-message, meta-messages needed to document it here, unless one is a language lawyer. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] OSC strings and Pd symbols
Hi all Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC]. Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console: --- unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not! --- I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations. The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception. Any thoughts on this are welcome. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
On Tue, 2012-03-13 at 09:11 +0100, Frank Barknecht wrote: > Hi, > > On Mon, Mar 12, 2012 at 06:36:25PM -0400, Hans-Christoph Steiner wrote: > > On 03/12/2012 06:06 PM, yvan volochine wrote: > > > On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote: > > >> IMHO, [routeOSC] should accept these two as the same thing: > > >> > > >> [/bla/1/blabli 0.437( > > >> [list /bla/1/blabli 0.437( > > >> > > >> It'll make life easier for a lot of people, and I can't see any > > >> disadvantage in that setup. > > > > > > well, in pd in general, [list foo bar( is not exactly the same as [foo > > > bar(, unless I'm missing something (if so, please, feel free to > > > enlighten me ;)). > > > > > > why not change also the behavior of [route] (and tons of other > > > objects) to make life easier for a lot of people ?? > > > > > > I don't really see the point.. [routeOSC] expects an OSC path, [list > > > /foo/bar 666( is obviously not one. > > > > > > my 20 COP anyway. > > > > I personally think it would be great to get rid of the separation > > between lists and non-list messages (i.e. lists of atoms that start with > > a symbol other than "list"). But that's a big project that will break > > backwards compatibility. > > > > Changing specific objects to ignore the difference can be done now > > without compatibility concerns. > > I don't believe that getting rid of the separation in general is a good goal. > > But I do agree, that ignoring the difference in some objectclasses can be > a useful time saver without introducing nasty side-effects. > > Some examples: > > In the rj library most objects use the last inlet solely for control messages, > i.e. special meta-messages to set the object's state. This inlet starts with a > [list trim] as its first operation effectively making list-messages with the > parameter name as first element the same as meta-messages where the parameter > name is the selector. "list frequency 440" is treated the same as "frequency > 440". The only disadvantage here is, that the object's inlet can not react in > a > special way to real "list"-messages. So what? I designed the objects so I > could > make sure none of them wants to do that, of if they want to, they can be > designed to use a different, often more memorizable selector like "notelist 60 > 62 64". (This is different from the general case in Pd where many objects > actually *do* special things with list-messages, most notably all message > boxes). > > The whole [list] object family except [list trim] (and the [list]-abs > collection as well) internally convert everything the other way around, into > "list"-messages and they output "list"-messages. This makes manipulating lists > much less error-prone. > > [routeOSC] obviously has worked fine in the past with the same approach, so I > don't think, it's of much use to force users to insert their own [list trim] > suddenly. It's not like in [route] where [route list] is indeed needed > sometimes (or was needed before [list trim] appeared). One could just as well > define [routeOSC] as an objectclass that routes pure OSC-messages as well as > OSC-messages that are embedded in a "list"-message. Control messages like > "verbosity 1" could still be used and the check, if a path is a proper > OSC-path > would just be applied to the first element of a list-message if necessary. > > So I'm not convinced. :) You're not convinced of what now? The proposal is actually what you describe above. Currently it _does_ make a separation between 'list' selector and 'OSC path' selector (it disregards messages with 'list' selector). Did you mean to say: 'Yeah, I'm convinced of the proposal to change [routeOSC]s behaviour to make it also messages with the 'list' selector'? Hans proposed to generally get rid of the separation between 'list' selector and 'any' selector messages in all parts of Pd. Personally, I'm undecided whether this is a good idea, but if it would be done, I'd consider it a bad approach to do it in every (external and internal) class separately. Rather should Pd's message system be changed. In this particular case, [routeOSC]'s behaviour is consistent with its brothers and sisters, since [unpackOSC] also outputs only messages with an OSC path as selector. Also for the documentation it's much more concise to state 'the selector of the incoming message is considered the OSC path' than 'the selector of the incoming messages is considered the OSC path, unless the selector is "list" where the first element of the message is considered the OSC path'. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vline~ precision, or sequentially segmented playback of a buffer
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: > I'm also wondering about the timing of tabread4~'s offset inlet being > updated. I get fewer clicks by tossing most of the patch into a > subpatch with [block~ 1]. I haven't checked really carefully, but > that does seem to make it so that clicks only occur where there are > gaps in the log.txt file. This also is the reason for the 181 msec clicks I get. Replacing the whole [list-sub] construction with a simple [$1, $2 $3( between [textfile] and [vline~] gives a nice and clean sound, except at the turnaround points where clicks are expected anyway. The offset-index of [tabread4~] is a message inlet that is not timing accurate, [tabread4~] will use the value from here at a different time than [vline~] uses its own copy of the value, leading to clicks. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] High end, low end (was : some other topic)
" the more advanced topics within - e.g. dynamic patching for me, or libPd according to Julian." "The high-end is the avant-garde" "Peace" Indeed. 2012/3/13 Mathieu Bouchard > Le 2012-03-13 à 02:09:00, András Murányi a écrit : > > > Hey, I was not quoting you. I was basically replying to Matju's mail >> which was basically replying to mine, in which I was trying to explain my >> idea about the importance of Pd staying accessible for amateurs, and one of >> the expressions I used the describe the "amateurs" was "low-end". Sorry if >> I made any confusion, by the time we arrived to "low-end" and "high-end" I >> was not having your previous posting on my mind any more. >> > > To me, the use of expressions low-end and high-end was clearly something > idiosyncratic, expressions that aren't used in the same way outside of this > conversation, just like one would invent new words in a casual manner. I > don't see them as corresponding to low art and high art. > > > __**__** > __ > | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mrpeach routeOSC behaves differently then its previous release?
Hi, On Mon, Mar 12, 2012 at 06:36:25PM -0400, Hans-Christoph Steiner wrote: > On 03/12/2012 06:06 PM, yvan volochine wrote: > > On 03/12/2012 02:54 PM, Hans-Christoph Steiner wrote: > >> IMHO, [routeOSC] should accept these two as the same thing: > >> > >> [/bla/1/blabli 0.437( > >> [list /bla/1/blabli 0.437( > >> > >> It'll make life easier for a lot of people, and I can't see any > >> disadvantage in that setup. > > > > well, in pd in general, [list foo bar( is not exactly the same as [foo > > bar(, unless I'm missing something (if so, please, feel free to > > enlighten me ;)). > > > > why not change also the behavior of [route] (and tons of other > > objects) to make life easier for a lot of people ?? > > > > I don't really see the point.. [routeOSC] expects an OSC path, [list > > /foo/bar 666( is obviously not one. > > > > my 20 COP anyway. > > I personally think it would be great to get rid of the separation > between lists and non-list messages (i.e. lists of atoms that start with > a symbol other than "list"). But that's a big project that will break > backwards compatibility. > > Changing specific objects to ignore the difference can be done now > without compatibility concerns. I don't believe that getting rid of the separation in general is a good goal. But I do agree, that ignoring the difference in some objectclasses can be a useful time saver without introducing nasty side-effects. Some examples: In the rj library most objects use the last inlet solely for control messages, i.e. special meta-messages to set the object's state. This inlet starts with a [list trim] as its first operation effectively making list-messages with the parameter name as first element the same as meta-messages where the parameter name is the selector. "list frequency 440" is treated the same as "frequency 440". The only disadvantage here is, that the object's inlet can not react in a special way to real "list"-messages. So what? I designed the objects so I could make sure none of them wants to do that, of if they want to, they can be designed to use a different, often more memorizable selector like "notelist 60 62 64". (This is different from the general case in Pd where many objects actually *do* special things with list-messages, most notably all message boxes). The whole [list] object family except [list trim] (and the [list]-abs collection as well) internally convert everything the other way around, into "list"-messages and they output "list"-messages. This makes manipulating lists much less error-prone. [routeOSC] obviously has worked fine in the past with the same approach, so I don't think, it's of much use to force users to insert their own [list trim] suddenly. It's not like in [route] where [route list] is indeed needed sometimes (or was needed before [list trim] appeared). One could just as well define [routeOSC] as an objectclass that routes pure OSC-messages as well as OSC-messages that are embedded in a "list"-message. Control messages like "verbosity 1" could still be used and the check, if a path is a proper OSC-path would just be applied to the first element of a list-message if necessary. So I'm not convinced. :) Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
