hi all,
i'd need a "set" message for the "value" object to access values that are represented by symbols stored in "pool".
i'm not sure, if there is any other way to do that. am i missing something? if so, please let me know...
if not, i hope nobody minds if i add that to the cvs ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i'd need a "set" message for the "value" object to access values that are represented by symbols stored in "pool".
I think I don't understand the question: There is a "set" message which works like:
set key value(s)
Later you "get" the value for a key with "get key"
Ciao
Frank Barknecht _ ______footils.org__
i'd need a "set" message for the "value" object to access values that are represented by symbols stored in "pool".
I think I don't understand the question: There is a "set" message which works like:
set key value(s)
sorry, i wasn't very detailed ... in the setup i'm working at, i have a pool object containing a list of symbols. each symbol represents a value object |value symbolxy|
what i want is accessing the |value| object using the output stream from pool.
to do that, i can either create each |value| by messages, or (what i would prefer) "set" the value... since object creation by messages for let's say 100 values is probably not very fast and the patch looks really ugly now, i'd prefer to use a setable value ...
of course, i can also write an external, but to me it would make more sense to implement it in pd itself...
cheers... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
sorry, i wasn't very detailed ... in the setup i'm working at, i have a pool object containing a list of symbols. each symbol represents a value object |value symbolxy|
Ah, okay, now I understand. I don't know if it helps with your problem, but are you aware, that "pool" also supports global pools, by naming the pool? pool names also are settable, so you may already have the settable [value] in [pool] - and then some.
what i want is accessing the |value| object using the output stream from pool.
to do that, i can either create each |value| by messages, or (what i would prefer) "set" the value...
I can see your motivation, but my usual caveat applies here as well: You would create two incompatible Pd version with doing that as an internal: MSP Pd and CVS-Pd. I don't think it's a good idea, in fact I'm convinced, doing this is a bad idea and would make all hell break loose. ;)
since object creation by messages for let's say 100 values is probably not very fast and the patch looks really ugly now, i'd prefer to use a setable value ...
I'm not really into the depths of the Pd source, but couldn't this create similar problems as settable sends/receives create? Also you could work with abstractions and pass the $0 from the parent patch as a creation argument. I do this extensively in RRADical to create somehow-non-local-but-still-not-totally-global variables.
of course, i can also write an external, but to me it would make more sense to implement it in pd itself...
Not if you consider my above caveat to be true and want to keep patch compatibility.
Ciao
Frank Barknecht _ ______footils.org__
hi all,
to do that, i can either create each |value| by messages, or (what i would prefer) "set" the value...
I can see your motivation, but my usual caveat applies here as well: You would create two incompatible Pd version with doing that as an internal: MSP Pd and CVS-Pd. I don't think it's a good idea, in fact I'm convinced, doing this is a bad idea and would make all hell break loose. ;)
first of all: it will not break anything. the cvs-pd will have a feature, the msp pd won't have. a msp patch will run on the cvs.
and: i'm convinced that it's not useful to keep pd as it is, just to remain the compatibility between cvs and msp. what we need is some way to integrate useful or neccessary stuff (like this, like the fftw support, like guenter's tooltips, like the threaded soundfiler, like thomas's simd stuffa) to the main pd branch. if each version of pd will be compatible to lower versions, i don't see any problem at all ... it's better than finding a workaround...
what we will need, is some kind of organization of the development, including a feature request and a bugtracking system that is used by everyone, users, developers and miller ... maybe we could use the sourceforge system or maybe someone knows / can set up another system ...
since object creation by messages for let's say 100 values is probably not very fast and the patch looks really ugly now, i'd prefer to use a setable value ...
I'm not really into the depths of the Pd source, but couldn't this create similar problems as settable sends/receives create? Also you could work with abstractions and pass the $0 from the parent patch as a creation argument. I do this extensively in RRADical to create somehow-non-local-but-still-not-totally-global variables.
there are no problems like with send/receive: if you want to send a "set" message, you will have a problem, but a |value| is only a storage for floating point numbers, so the message "set" to the |value| won't be used for something else... also, setting a "receive" is probably useful. for a setable send, we would either have to use a second inlet or use a message ...
cheers... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
first of all: it will not break anything. the cvs-pd will have a feature, the msp pd won't have. a msp patch will run on the cvs.
You cheat: It *will* break msp-pd, which won't run patches done on cvs-pd if those use your "set value". And to me at least MSP Pd is the canonical definition of the Pd syntax.
and: i'm convinced that it's not useful to keep pd as it is, just to remain the compatibility between cvs and msp. what we need is some way to integrate useful or neccessary stuff (like this, like the fftw support, like guenter's tooltips, like the threaded soundfiler, like thomas's simd stuffa) to the main pd branch.
Changing builtin objects is *not* just adding a new "feature". You are trying to change the *rules* of the Pd *language*, which all Pd versions still share.
if each version of pd will be compatible to lower versions, i don't see any problem at all ... it's better than finding a workaround...
Either way I'd like to keep all current versions at least be able to understand each other, to speak the same language. If you want to extend the language by defining new words, that's fine. That's what functions or typedefs in programming languages do, and that's what externals do in Pd.
But your change is like changing a standard header file, so to say. Why do you want to introduce an incompatibility without need? Write an external and everyone is happy. value is defined using 114 lines of code, so writing an extended "value" external would be done in some minutes, it just means adding one function of 3 or 4 lines code. If you keep the code similar to the "value" code then it would be easy to add this to MSP Pd as well later.
But please don't change the language just because you need a missing feature, which wasn't missed by anyone else as long as I can remember reading this list.
Ciao
Frank Barknecht _ ______footils.org__
hi frank, hi list
Either way I'd like to keep all current versions at least be able to understand each other, to speak the same language. If you want to extend the language by defining new words, that's fine. That's what functions or typedefs in programming languages do, and that's what externals do in Pd.
i definitely see your point, but imo the _language_ pd has a few weak points... like change only working for floats, right inlet of "symbol", or the dynamic setting of values... imo, externals should not be written, if they just add one feature to a core object ...
since you are objecting, i _will_ write an external for that ... but there should be a discussion about extending the language ... a discussion between users, developers and miller...
But please don't change the language just because you need a missing feature, which wasn't missed by anyone else as long as I can remember reading this list.
and that i missed several times... ;-)
cheers... tim
Hallo Tim, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
since you are objecting, i _will_ write an external for that ... but there should be a discussion about extending the language ... a discussion between users, developers and miller...
I heartily agree here: I don't think, too, that the Pd core language should stay fixed, and changes should be suggested, discussed and also implemented. However it is very important to then include core changes to all versions (which basically are only 2.5 currently: MSP, CVS and imPD) at the same time. The reason is, that the language is the common ground for all. If I do a workshop again, I wouldn't want to have to tell people: "Well, this patch does only work with the CVS version." Beginners might not even know what version they run. I think, the disadvantages of changing the core outweight the gain here. But maybe someone else has another opinion?
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 21 Jul 2004, Frank Barknecht wrote:
tell people: "Well, this patch does only work with the CVS version." Beginners might not even know what version they run. I think, the disadvantages of changing the core outweight the gain here. But maybe someone else has another opinion?
The CVS version was always meant as a developers version only. I think that a good way of beeing able to figure out the advantages and disadvantages is having them implemented. I never ever told someone in class to use the CVS version. I always point them to Millers version.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
The CVS version was always meant as a developers version only. I think that a good way of beeing able to figure out the advantages and disadvantages is having them implemented. I never ever told someone in class to use the CVS version. I always point them to Millers version.
Me, too, because that's the canonical one. But still: what version is in Debian testing? ;)
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 21 Jul 2004, Frank Barknecht wrote:
Me, too, because that's the canonical one. But still: what version is in Debian testing? ;)
Currently a different one. Out of a good reason .. I just say "expr".
Guenter
Ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Wed, 21 Jul 2004, Frank Barknecht wrote:
tell people: "Well, this patch does only work with the CVS version." Beginners might not even know what version they run. I think, the disadvantages of changing the core outweight the gain here. But maybe someone else has another opinion?
The CVS version was always meant as a developers version only. I think that a good way of beeing able to figure out the advantages and disadvantages is having them implemented. I never ever told someone in class to use the CVS version. I always point them to Millers version.
i changed the code of the value object ... i could:
- add it to devel_0_37
- add it to devel_0_37, but enable it only with the configure script and post a warning when creating an object (i'd prefer that)
- add it as external to the cvs...
i'd like to hear, what other people would prefer ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i changed the code of the value object ... i could:
- add it to devel_0_37
I don't like that.
- add it to devel_0_37, but enable it only with the configure script and post a warning when creating an object (i'd prefer that)
I could live with that. If this is the outcome, then the configure option should be unified for all future non-standard language features, and should be disabled per default, so that it doesn't unintentionally find its way into any distribution packages.
- add it as external to the cvs...
I'd prefer that, it's the well tested and IMO best way of extending the language.
Cyclone is a great example of this approach: Cyclone is designed to get easily incorporated into the core Pd language, and still stays externals, so people can try it out, without creating a language branch. expr~ et al. is another example.
(Basically I already said all this, I'm just recapitulating it.)
Ciao
Frank Barknecht _ ______footils.org__
Hi all
I can't remember if I mentioned this, but I want to make future versions of Pd allow users to rename built-in objects via the command line so that you could run "pd -rename value sauerbraten" and then load a "value" external without incident.
I still find it hard to figure out whether it's a good idea or not to extend objects in non-Max-compatible ways. In the case of "value" it's doubly complicated, since the current Max version might be unnecessarily baroque (although I haven't looked at it yet to know.)
I also don't know whether having a settable name for value is correct, or whether it is a better design to have an entirely different object which can switch among value objects (the way tabread can switch between tables for instance.) That would be more trouble to use but more consistent with the rest of Pd...
cheers Miller
On Fri, Jul 23, 2004 at 12:17:17AM +0200, Tim Blechmann wrote:
On Wed, 21 Jul 2004, Frank Barknecht wrote:
tell people: "Well, this patch does only work with the CVS version." Beginners might not even know what version they run. I think, the disadvantages of changing the core outweight the gain here. But maybe someone else has another opinion?
The CVS version was always meant as a developers version only. I think that a good way of beeing able to figure out the advantages and disadvantages is having them implemented. I never ever told someone in class to use the CVS version. I always point them to Millers version.
i changed the code of the value object ... i could:
- add it to devel_0_37
- add it to devel_0_37, but enable it only with the configure script and post a warning when creating an object (i'd prefer that)
- add it as external to the cvs...
i'd like to hear, what other people would prefer ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I still find it hard to figure out whether it's a good idea or not to extend objects in non-Max-compatible ways. In the case of "value" it's doubly complicated, since the current Max version might be unnecessarily baroque (although I haven't looked at it yet to know.)
I now looked up "value" in the Max Reference PDF, and there value can keep all kinds of messages, also lists and symbols, not only floats. Interestingly enough, the example patch shows sending a "set something" message through a [value] object which is then used to "set" a message box to read "something" after a second value.
So a "set" as suggested by Tim would not only introduce a new extension compared to Max, it would also render a certain direction in the future development of "value" invalid.
(Further in the doc, "value" in Max indeed gets slightly baroque: It accepts a "send receivername" message, to send the stored value to any receive of the name "receivername", rendering value as being another kind of "send")
I also don't know whether having a settable name for value is correct, or whether it is a better design to have an entirely different object which can switch among value objects (the way tabread can switch between tables for instance.) That would be more trouble to use but more consistent with the rest of Pd...
I never looked at it that way, but it sounds like a good solution. Trouble can always be hidden inside abstractions (the famous "another level of indirection"). But still I don't really see the need to have value setable. For one there already is [pool], which is a setable, optionally global container for lots of data -- a [value] on steroids. And then: although I use pool all the time, I seldom feel the need to change ("set") the pool's name.
Ciao
Frank Barknecht _ ______footils.org__
Miller Puckette wrote:
Hi all
I can't remember if I mentioned this, but I want to make future versions of Pd allow users to rename built-in objects via the command line so that you could run "pd -rename value sauerbraten" and then load a "value" external without incident.
but wont this make patches much much less portable? if you get used to
using these flags, in order to tell someone else how to use your patch
not only will you have to have a list of which externals you use, but
also which individual objects you subsitute out on the command line.
chances are it will come up that you wont be able to run patches
designed by two different people (who have different substitution flags)
at the same time in the same instance of pd.
Agreed - it's always going to be hard to maintain patches that rely on versions of objects that differ from the built-in ones! However, for people who just _have_ to do it, it seems appropriate to provide a way.
M
On Fri, Jul 23, 2004 at 09:27:35AM -0700, Josh Steiner wrote:
Miller Puckette wrote:
Hi all
I can't remember if I mentioned this, but I want to make future versions of Pd allow users to rename built-in objects via the command line so that you could run "pd -rename value sauerbraten" and then load a "value" external without incident.
but wont this make patches much much less portable? if you get used to using these flags, in order to tell someone else how to use your patch not only will you have to have a list of which externals you use, but also which individual objects you subsitute out on the command line.
chances are it will come up that you wont be able to run patches designed by two different people (who have different substitution flags) at the same time in the same instance of pd.-- ________________________________________________________________ live experimental electronic music -- http://bluevitriol.com independent u.s. drum'n'bass -- http://vitriolix.com
Miller Puckette wrote:
Agreed - it's always going to be hard to maintain patches that rely on versions of objects that differ from the built-in ones! However, for people who just _have_ to do it, it seems appropriate to provide a way.
...
On Fri, Jul 23, 2004 at 09:27:35AM -0700, Josh Steiner wrote:
...
but wont this make patches much much less portable? if you get used to using these flags, in order to tell someone else how to use your patch not only will you have to have a list of which externals you use, but also which individual objects you subsitute out on the command line.
chances are it will come up that you wont be able to run patches designed by two different people (who have different substitution flags) at the same time in the same instance of pd.
and, even if two people had exactly same "-rename" substitutions, they risk running two different "value" externals...
So, I guess, the opposite way in which Max does this, is a bit safer. There is a mapping file, in which Tim might be willing to put a line:
max objectfile value bettervalue
and call his enhanced version plain [value] in his patches.
Then, anybody having "bettervalue" installed, will be able to run Tim's patches, provided these are somehow bundled with the mapping (a maxer would use a "collective"). No way of using Tim's patches as abstractions, though...
Krzysztof
So, I guess, the opposite way in which Max does this, is a bit safer. There is a mapping file, in which Tim might be willing to put a line:
max objectfile value bettervalue
i'm not a big fan of this (both a mapping file and a -rename flag), since this _will_ make pd patches uncompatible to other machines using the same pd version. if we do something, let us better discuss small changes that make our life easier so that we won't need a mapping file or a -rename flag.
Then, anybody having "bettervalue" installed, will be able to run Tim's patches, provided these are somehow bundled with the mapping (a maxer would use a "collective"). No way of using Tim's patches as abstractions, though...
that's the problem ... portability of patches should be our first priority, the second priority is to be compatible to future versions, but not neccessary to older versions...
cheers ... tim, who is really happy, that there is a discussion about developing pd not about organizing development.
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
So, I guess, the opposite way in which Max does this, is a bit safer. There is a mapping file, in which Tim might be willing to put a line:
max objectfile value bettervalue
i'm not a big fan of this (both a mapping file and a -rename flag), since this _will_ make pd patches uncompatible to other machines using the same pd version.
As I understand Miller's motivation, this option would only be for things like developement. THis way you could test some changes to builtin objects without having to recompile Pd all the time.
that's the problem ... portability of patches should be our first priority, the second priority is to be compatible to future versions, but not neccessary to older versions...
Currently we have another problem: That there are 2.5 parallel versions, which are neither older or newer than each other. (Or you could say, that currently Miller's version is the newest, this might change again this weekend. ;)
Ciao
Frank Barknecht _ ______footils.org__
Hello,
I'm looking for a way to store messages in sequence, but beinging able to replace them again, something like an array in perl maybe ( or a list in gtk where I can replace an entry)
with |textfile| or |qlist| I could not find a way to 'update' individual lines.
I'm hanling one or two messages at a time, every 40 ms. I'm thinking 'macro' recorder for osc/VIMS commands, ( an application (veejay) is receiving and the messages, and sending the keys pressed back etc. ) being able to change parameters in playback dynamically. A bit like a 'pattern editor' in soundtracker of fastracker, where you can 'play' over existing sampling entries, in the way of handling it ( not graphically, but when something 'pattern' alike exists I'd like to know)
is there some external I could use? or did I miss something in the PD docs?
If there's more sources of documentation then mentioned on iem I'd like to read them.
cheers!
Matthijs.
Hallo, MvH hat gesagt: // MvH wrote:
A bit like a 'pattern editor' in soundtracker of fastracker, where you can 'play' over existing sampling entries, in the way of handling it ( not graphically, but when something 'pattern' alike exists I'd like to know)
RRADical (in CVS abstractions/rradical) contains a bunch of pattern sequencers. the newest, rrad.nseq, is a keyboard-enabled number sequencer modelled after tracker interfaces. All RRADical patches are saveable and can be remote controlled using OSC. There is a very new module as well which can save the state to a textfile containing OSC messages, it's called careOSC.pd
is there some external I could use? or did I miss something in the PD docs?
pool is good for this and required for RRADical.
Ciao
Frank Barknecht _ ______footils.org__
is there some external I could use? or did I miss something in the PD docs?
pool is good for this and required for RRADical.
pool is a very useful external, but if you are only working with lists, you could have a look at zl in cyclone....
cheers... tim
Tim Blechmann TimBlechmann@gmx.net writes:
pool is a very useful external, but if you are only working with lists, you could have a look at zl in cyclone....
or [coll], as a replacement for [qlist] or [textfile], also in cyclone.
ciao
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
As I understand Miller's motivation, this option would only be for things like developement. THis way you could test some changes to builtin objects without having to recompile Pd all the time.
recompiling pd is something that can be done within one or two minutes ... when you are working on an external and only changing one file, you just have to recompile the file you changed and link the objects ... thanks why there is the make tool ...
Currently we have another problem: That there are 2.5 parallel versions, which are neither older or newer than each other. (Or you could say, that currently Miller's version is the newest, this might change again this weekend. ;)
since i commited miller's changes to the devel_0_37 branch, it is the newest one again ;-)
but you are right ... having two or three branches is not very good for the development... it's not really good if there is one version with development in the dsp core (msp), one with development in the gui (impd) and one with different additions (devel_0_37). basically miller is working on the core, mathieu on the gui, and a few other people like thomas, guenter and me on some other features ... we all agree that miller's branch is the official branch, the language definition. i don't know, if it's useful to have mathieu's and miller's development divided to two different cores... if mathieu is working on one part of the main branch (the gui) and miller on the other part (core), they should work on the same branch. also things like thomas's inlined simd code (which is far better than anything gcc or icc produced, i checked the machine instructions and did some profiling), like guenther's tooltips (which are _very_ useful for to use in abstractions) or my fftw support (more than twice as fast as the mayer-fft, and selectable at compile-time) or threaded soundfiler (which has been reported to work on win, osx and linux) or yves patch for a threaded gui (i have to use it for my performance patch to be click-free)...
and i doubt that we should reinvent the wheel several times by rewriting something that is available in another branch...
cheers ... tim, who is hoping to see one stable branch and one development branch that will be a future stable branch...
I compiled pdp but when I run it I don't get an image. I tried the input_output.pd patch with no success. Below is what I get in the terminal window after creating a window opening pdp_v4l and banging it once. I tried pdp_xv and pdp_glx with no luck. I can see the video with Gem and xawtv so I think video4linux is ok. Any thought where I should start to look for problems. I'm using a logitech usb based webcam. Thanks. Jim Sample width set to 2 bytes PDP: pure data packet PDP: version 0.12.3 pdp_xvideo: grabbed port 61 on adaptor 0 pdp_v4l: opening /dev/video0 pdp_v4l: cap: name Logitech USB Camera type 513 channels 1 maxw 352 maxh 292 minw 32 minh 32 pdp_v4l: picture: brightness 32767 depth 24 palette 4 pdp_v4l: channel 0 name Camera type 2 flags 0 pdp_v4l: switched to channel 0 pdp_v4l: set norm to 0 pdp_v4l: buffer size 426240, frames 1, offset 0 0 pdp_v4l: using VIDEO_PALETTE_YUV422 pdp_v4l: frame 0 0, format 7, width 320, height 240 pdp_v4l: Opened video connection (320x240) pdp_v4l: VIDIOCMCAPTURE: Invalid argument pdp_v4l: VIDIOCMCAPTURE2: Invalid argument pdp_v4l: frame 1 1, format 7, width 320, height 240 pdp_v4l: VIDIOCSYNC: Bad file descriptor pdp_v4l: no device opened pdp_v4l: attempting auto open pdp_v4l: opening /dev/video0 pdp_v4l: cap: name Logitech USB Camera type 513 channels 1 maxw 352 maxh 292 minw 32 minh 32 pdp_v4l: picture: brightness 32767 depth 24 palette 4 pdp_v4l: channel 0 name Camera type 2 flags 0 pdp_v4l: switched to channel 0 pdp_v4l: set norm to 0 pdp_v4l: buffer size 426240, frames 1, offset 0 0 pdp_v4l: using VIDEO_PALETTE_YUV422 pdp_v4l: frame 0 0, format 7, width 320, height 240 pdp_v4l: Opened video connection (320x240) pdp_v4l: VIDIOCMCAPTURE: Invalid argument pdp_v4l: VIDIOCMCAPTURE2: Invalid argument pdp_v4l: frame 1 1, format 7, width 320, height 240 pdp_v4l: VIDIOCSYNC: Bad file descriptor pdp_v4l: auto open failed
hi list, everytime i multiply a signal with 0 or 1 i hear a clicking sound... what can i do for avoiding this?
thanx
siggmus
#N canvas 0 0 1006 682 10; #X obj 324 365 osc~; #X floatatom 324 319 5 0 0 0 - - -; #X obj 322 585 dac~; #X obj 321 529 *~ 0.4; #X obj 321 475 *~ 1; #X msg 490 358 1; #X obj 324 253 loadbang; #X msg 438 359 0; #X connect 0 0 4 0; #X connect 1 0 0 0; #X connect 3 0 2 0; #X connect 3 0 2 1; #X connect 4 0 3 0; #X connect 5 0 4 1; #X connect 6 0 1 0; #X connect 7 0 4 1;
Hallo, siggmuss hat gesagt: // siggmuss wrote:
hi list, everytime i multiply a signal with 0 or 1 i hear a clicking sound... what can i do for avoiding this?
Interpolate with line~. Like this:
[x] <- toggle
|
[pack 0 10]
|
[osc~] [line~] \ / [*~]
Ciao
Frank Barknecht _ ______footils.org__
hi all,
Interpolate with line~. Like this:
i'm not sure if it is needed to use a |line~| object for these tasks. recently, i replaced all |line~|s with |line 0 5|, that are using a control rate of 5ms / 200 Hz. before that i did some profiling on my patch and saw that |line~| is using quite some cpu power. since |line| is sending messages, the |*~| will not perform a signal/signal multiplication, but a signal/scalar multiplication.
i don't hear any clicks (at 5ms control rate and |line|s of about 100ms) and if you don't want to create fancy envelopes, but only have a volume fader, a line should be enough ...
cheers ... tim
-
Frank Barknecht -
guenter geiger -
jim ruxton -
Josh Steiner -
Krzysztof Czaja -
Michal Seta -
Miller Puckette -
MvH -
siggmuss -
Tim Blechmann