Pd-list March 2008

pd-list@lists.iem.at

150 participants
274 discussions

editmode for datastructures
by marius schebella 14 Mar '08

14 Mar '08

hi, I guess that is not possible... I am using plot to draw an array, then select the array in editmode and drag it around. is there any possibility to get the new absolute position? I really doubt this is possible... too bad. Btw. I also would like to be able to change the length of a plot, add/delete values, maybe with shiftclick? and there is also no possibility to use a table-array as an input source for a datastructure array. and does selecting and duplicating actually create new data? and btw the intro file for the datastructures still talks about "templates" can I replace template with "struct"? and btw pix_dump of a 100*100 image freezes pd. (probably has something to do with console output on OS X?) cheers, marius.

1 0

Re: [PD] Guitar Heroes controller
by James Rojsirivat 14 Mar '08

14 Mar '08

I wonder if the one that comes with the PC/Mac version makes a different. I think it's USB and meant to work on the computer. I'm going to get the game this weekend at the Apple Store and try to play around with it. Well, both the game and the controller. James *************************************************** astroboy2520 Visit my blogs: http://triphop-universe.blogspot.com http://videokilledtheradiostar.vox.com Myspace: http://www.myspace.com/astroboy2520 Skype: astroboy2520 MSN: astroboy2520[at]sbcglobal.net **************************************************** ----- Original Message ---- From: Hans-Christoph Steiner <hans(a)eds.org> To: shima(a)pspunch.com Cc: pd-list(a)iem.at Sent: Thursday, March 13, 2008 12:10:44 PM Subject: Re: [PD] Guitar Heroes controller Yeah, my hardware is specifally labeled PS2. It has a USB port, it shows up properly like a USB HID device, just no data comes out :( .hc On Mar 13, 2008, at 3:17 AM, PSPunch wrote: > > Hans, > > > Is your hardware labeled to be specifically for PS2? > > At least this one article mentions that the hardware is equal among > all > platforms. > http://www.hwhell.com/articles/gametrak-hardware-review > > If you are using a generic PS2 <-> USB converter, it does seem likely > that the converter is filtering obscure data other than the > conventional > buttons. i.e., the one I use filters out only the input from the > analog > keys. > > > >> On a related note, I just bought one of these very nice controllers >> called a gametrak. It is basically like two 3D joysticks but instead >> of sticks, it has strings which you can clip on to things to track >> them in 3D. The cheesy promo video gives you a good idea of what you >> can do with it: >> >> http://www.in2games.uk.com/corporate/press-item.php?pressid=5 >> >> I used one that Jonas Hielscher let me borrow and I plugged it in and >> it just worked with [hid]. I just got the one I ordered, it is a >> "PlayStation 2" controller, I am not sure which Jonas' is. But with >> mine, it shows up in [hid] fine, but I don't get any data from it. >> >> Anyone know, is there something special about PS2 USB controllers? >> >> .hc >> >> >> On Mar 12, 2008, at 8:12 PM, Derek Holzer wrote: >> >>> Should just be HID protocol. Check the help patch for the [hid] >>> object >>> (in Extended or self-compiled) and see what parameters come in. >>> After >>> that, enjoy mapping them to something and rock out! >>> >>> d. >>> >>> James Rojsirivat wrote: >>>> I've seen some developments with the Guitar Heroes controller on >>>> Max/MSP. I've been unable to get the one patch I found to really >>>> open in >>>> PD. I'd love to try to do something with it. Anyone has any >>>> experience >>>> developing and working with the Mac/PC version of the controller >>>> in PD? >>>> Any tips would greatly be appreciated. >>> -- >>> derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ >>> macumbista >>> ---Oblique Strategy # 71: >>> "Fill every beat with something" >>> >>> _______________________________________________ >>> PD-list(a)iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >>> listinfo/pd-list >> >> >> >> --------------------------------------------------------------------- >> --- >> ---- >> >> There is no way to peace, peace is the way. -A.J. Muste >> >> >> >> _______________________________________________ >> PD-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list >> > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- "It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White _______________________________________________ PD-list(a)iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

1 0

Re: [PD] [almost OT] need suggestions for an implementation
by Matteo Sisti Sette 14 Mar '08

14 Mar '08

Roman Haefeli wrote: > > Some people may miss [s2l] in vanilla Pd, others miss a [pipe] for > > variable length lists or a multi-period [metro], > > those can all be done with built-in objects already, as far as i can see > (with more or less effort, though). I can't see how you could implement a [pipe] for variable-length lists with built-in objects, no matter how much effort you put in it (with acceptable memory/cpu costs).

2 4

A Few GSoC Project Ideas
by Greg Surges 13 Mar '08

13 Mar '08

Hi, As a student who is *very* interested in taking part in the PD project under Google Summer of Code, I thought I'd throw a few ideas out and see what other people thought of them. These are all things I'd be interested in pursuing. 1. A set of externals designed for real-time, high-level analysis of control data. This could include things like histograms, rhythm analysis, rate-limiting and data-filtering objects, all designed for use on a constant stream of input. 2. A set of externals designed to make string assembly and parsing much easier, particularly geared towards the creation of OSC messages. 3. Finally, a set of band-limited oscillators, to allow for spectrally rich waveforms without aliasing. Any thoughts? Thanks everyone, Greg -- http://www.uwm.edu/~gssurges/ <http://www.uwm.edu/%7Egssurges/%20>

5 4

Guitar Heroes controller
by James Rojsirivat 13 Mar '08

13 Mar '08

I've seen some developments with the Guitar Heroes controller on Max/MSP. I've been unable to get the one patch I found to really open in PD. I'd love to try to do something with it. Anyone has any experience developing and working with the Mac/PC version of the controller in PD? Any tips would greatly be appreciated. *************************************************** astroboy2520 Visit my blogs: http://triphop-universe.blogspot.com http://videokilledtheradiostar.vox.com Myspace: http://www.myspace.com/astroboy2520 Skype: astroboy2520 MSN: astroboy2520[at]sbcglobal.net ****************************************************

4 4

Re: [PD] A Few GSoC Project Ideas
by Greg Surges 13 Mar '08

13 Mar '08

Andy, Hans-Christoph, and everyone else, I've created wikis for the analysis and blosc ideas. I think a major advantage for the analysis library would come from issues of speed. When I've done PD code that does a simple sort on an array (used for a histogram), it takes an incredibly long time - long enough to interfere with other real-time processes. It seems to me, and maybe I'm incorrect, that writing externals in C would prove to be much faster and more efficient. As far as the band-limited oscillators, the externals/abstractions that I've found have been problematic or not worked at all. That really seems like something that should be fixed. Thanks guys, -Greg -- http://www.uwm.edu/~gssurges/

2 1

inflating PD-Vanilla (was Re: [almost OT] need suggestions for an implementation)
by Matteo Sisti Sette 13 Mar '08

13 Mar '08

I do totally agree that [pdlua] is a great thing and that it would be desirable to have it become part of PD-Vanilla. Nevertheless, Frank Barknecht wrote: > Some people may miss [s2l] in vanilla Pd, others miss a [pipe] for > variable length lists or a multi-period [metro], a flexible markov > chain object and whatnot. With pdlua most of this is almost trivial to > write and can be installed without the need to compile anything once > pdlua is installed. We first have to distinguish between A) things that can already be achieved IN vanilla pd by creating abstractions on top of built-in objects B) things that can not. Within category (A), there are things that would either result in a horribly inefficient implementation or require some hugly hack, so they deserve to be treated like case (B). Think for example about the "old" [list-length] abstraction that returned the length of a list by scanning it and counting its elements: it implemented the same funcionality of the later built-in [list length], yet it was quite desirable to have a built in object to do that. Probably better examples can be found. Except these cases, I think that externals that solve class-A problems are not candidate to becoming part of PD Vanilla. Now about class B that is the one I'm concerned with. It's great to include a high-level interpreted language in PD that lets one create all the extensions s/he wants, but that doesn't mean that, if this extension language (lua) became part of PD Vanilla, ANY built-in object whose functionality could be obtained with a lua script would become unnecessary! True: if [pdlua] was part of PD Vanilla, you wouldn't strictly "need" a [symbol2list] (or splitsymbol or whatever) object. But then you wouldn't need [*], [-], [sqrt], [cos], [list ...], [moses], [until]...... probably not even [trigger]. Would you imagine how pd patches would look like?? It is, I think, a matter of "elegance" (which means that it is subjective, I recognize). Let me make a parallelism. I always missed [>=~], [==~], [abs~], etc.; I was quite astonished to find out they didn't exist when I first needed them, and I never understood why they didn't, until [expr~] became part of PD Vanilla, or probably until I _realised_ that [expr~] _was_ part of PD Vanilla. Now I still think they should exist, as I find ugly to write [expr~ $f1>=$f2] (or whatever it is) instead of [>=~]. I think it is a matter of elegance and consistence that every control math operator should have its signal counterpart. Now i'm SURE there are good reasons why basic signal math operators don't exist, I haven't even searched the archives but i'm sure I'll find out something about it, however take this as an _example_. Now I think breaking symbols is just another example; and like a couple of people have said in this thread, since you can join them it's reasonable to expect you can break them just as easily. Bye m.

3 2

Re: [PD] Clocks and [pipe] in Lua
by Matteo Sisti Sette 13 Mar '08

13 Mar '08

Thanks a lot to Claude for the code and to Frank for the line-by-line explanation!!! :))

1 0

Re: [PD] [almost OT] need suggestions for an implementation
by matteo sisti sette 13 Mar '08

13 Mar '08

Frank wrote: > Why care? [about how efficient pipe is] There's not much > you can do about it, if it's too slow, > except writing a better [pipe] in C/Lua/etc. Well that's exactly why I need to know: to decide whether I need to write a "better" [pipe] in Lua or not!! > An approach carmen did > in the past is to use list2symbol and symbol2list (the latter an > external) Yes that's an interesting solution! I usually try to go as far as possible in pd-vanilla without any external.... but maybe I've reached the "as far as possible". You may argue that I am reluctant to use an external while I would use pdlua, but one thing is to install an external that solves a specific problem, another thing is to install one single extension mechanism (pdlua) that allows you to develop any "externals" (especially when we're talking of externals for manipulating data, not for using hardware etc). I think it's a pity that PD Vanilla doesn't include [symbol2list] or any objects capable of "breaking" symbols a little bit (with which one could build a symbol2list abstraction and maybe more), since it does give the possibility to join symbols. Note that with [makefilename] and using the standard syntax of sprintf-like funcions (namely %.<n>s where <n> is a number) you can take the first n characters of a symbol: if only there were a way to take the remaining characters (or a way to know a symbol length + a way of taking the last m characters), one could build a symbol2list abstraction, or split a symbol into its characters etc. .....well now I'm thinking the length of a symbol _can_ be calculated, in a loop which at iteration k takes the first k characters and compares the result with the whole symbol..... so the missing piece is the possibility to take the last n chars... or is it not? Thank you very much for the help. Ciao m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

3 3

Clocks and [pipe] in Lua
by Frank Barknecht 13 Mar '08

13 Mar '08

Hi (Claude), inspired by Matteo's question I briefly tried to implement a [pipe] clone in pdlua, however I ran into problems which might hint at either some design issues with clock support in pdlua or, more likely, my lack of understanding how clocks work. Anyway here's the problem: [pipe] in Pd is an object which as far as I understand the code creates lots of pd-clocks as part of a "hang-list" where pending events are collected. So the workflow is like this: Everytime [pipe] receives a message, it creates a new "t_hang" structure item (in a list of these) with the message payload and a new clock inside. That clock is set to call back hang_tick(t_hang *h) after a delay. When its time has come, hang_tick sends the payload to the outlet and destroys the t_hang-object including the clock afterwards. For the luapipe [lpipe] I thought I'd mimick that approach and collect the scheduled events in a table as member of the pdlua-class, like self.events. So the method to add an event could look like this in pseudo-Lua: function M:in_1(sel, atoms) local deltatime = atoms[1] -- delay local e = event.new() e.payload = atoms e.clock = makeclock(deltatime) table.insert(self.events, e) end My problem is the hypothetical "makeclock". It should be a clock that somehow is tied to the event. But as I see it, clocks in pdlua are supposed to be tied to a pdclass object itself, and their callback methods don't accept any additional arguments to specify which of the event they should handle. Any ideas how to work around this? Ciao -- Frank Barknecht _ ______footils.org__

3 4

← Newer
1
...
14
15
16
17
18
19
20
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list March 2008