Grammostola Rosea schrieb: i don't know what is possible with pd and csound in supercollider it is not really intended to use with csound. i personally would say that the sound is the same ... but there are always some esoteric around. one point is that it is not that easy to setup a multiphonic synth in pd. currently there is no video suport in sc and csound and i don't think in chuck. somebody is writing a Supercollider supported OpenGL-server but this is not finished now.

On Thu, Sep 3, 2009 at 11:04 PM, Grammostola Rosea<rosea.grammostola(a)gmail.com> wrote: yes, directly using csoundapi~ or indirectly using midi/osc messages this is my first video, just an effort to learn gem (+pd) http://vimeo.com/6070078/ ps: this is a video, not art ;) ciao -- http://msound.org

Grammostola Rosea wrote: You mean controlling csound by algorithms from pure data? I never got the grip of doing intensive logic in pd. In chuck I can just do a if-then-else, like while(true) if(nb_notes_played >= Std.rand2(5,9)){ 0 => osc.gain; Time.beat() * Std.rand(2,5) => now; 1 => osc.gain; 0 => nb_notes_played; } else { Std.mtof(Global.randomArrayElement(scale)) => osc.freq; Time.beat() * 0.5 * Std.rand(1,3) => now; nb_notes_played++; } Did you get that? Plays phrases of 5-9 notes with lengths between a 1/8 note and a dotted 1/4 note, frequencies randomly selected from a scale. In between phrases make a rest of between 1 to 5 beats. The above is not tested, assumes some defs to go before it, and is not that pretty. But (when tested) it works, it took my < 1 min to write here and it's easy to play around with lengths of notes and rests, try other scales, put restraints on note selection (use your counterpoint rules), etc. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Dave Phillips wrote: I found this so far http://supercollider.sourceforge.net/2008/scgraph-a-3d-graphics-server-for-… \r

Grammostola Rosea wrote: I think that is an excellent thought. I'd prefer csound as a backend, though :-) I imagine PD would fit the bill best, though. Imagine a PD VST/VSTi that came with presets (PD patches saved in a folder) and allowed the user to add her own. The underlying PD should be invisible to the user (so no need to do external install), just place the pd.so (with accompanying patch folder) in your ~/.vst and off you go. It could input/output midi and audio, so extreme arpeggiators or algoritmic composition would be within reach. Haven't tried it, but I imagine this is possible with the newly discussed Ableton Live/Max combo. Of course the more native linux plugin standards (dssi, ladspa, lv2), could also be a way to go, but I'm using a host that understands VST, VSTi and ladspa (I think not dssi). Maybe dssi would be the most appropiate, then we "just" need to convince devs to support dssi. I have no idea, however, if such a plugin has been atempted or how possible it would be... -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Grammostola Rosea wrote: Because I worked with csound 10 years :-) Well for this kind of thing (not building an environment, but making noise from midi) supercollider seems less appropriate than PD. I used pd (stand-alone) this way, both to process midi and make noise, in a few projects (muse, ardour, specimen, zyn, that kind of setup). And it's graphical approach seems like seamless integration in a gui environment would be possible. That said I (as mentioned a few times) haven't done that much in super collider, so I might not be the person to say anything against such a solution. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Atte Andre Jensen wrote: Thanks for searching. In my search to an environment I got the feeling that SuperCollider is a more modern language, a language for the future so to say. It's better suitable to compete those VST plugins maybe... I can see that is seems to be more easy to make a PD gui, but this should be possible with SC too right? Don't know if the language is ready for that yet. Please post also a message to the SC mailinglist, then you get a more general/objective view... Regards, \r

I guess you refer to Faust which can generate several formats and plugins http://faust.grame.fr/ There is also csLadspa which converts csound patches to Ladspa plugins. But actually you guys lost me a bit, what is so important about the plugin paradigma? The only benefit I can see is total recall but apart from it I see no use over using stand alone applications. The plugin idea comes from closed source environment which doesnt allow to make interapplication connection like you can do now and here with Jack and Alsamidi. Cheers, Malte -- ---- media art + development http://www.block4.com new software released: contrOSC, control your Mackie C4 with OSC http://controsc.sourceforge.net

On Mon, 14 Sep 2009 02:31:33 +0200 Malte Steiner &lt;steiner(a)block4.com&gt; wrote: Ah, yes, Faust it was then, thanks. The lack of a proper session management system is the biggest problem I see atm.. Making plug-ins in multiple formats easily without having to learn the plug-in APIs is a good thing in general. Less APIs to learn means more time and effort can be put into the code that matters. Philipp

Grammostola Rosea wrote: I tend to agree. However don't dismiss either pd or csound too early. They are both very powerful pieces of software, that let's you do very, very deep stuff. Each has it's advantages (enough for many a flame war), granted, but still, all are very powerful. May I ask if you checked out any of the grand three and the baby one (csound, pd, super collider and chuck)? If not, I have to repeat the almost generic advise often given here: Get your feet a little bit wet with each (do a tutorial, for instance) to get a quick overview of what they can do and how they feel. Then pick one, stick wíth it, work with it, live with it, create music in it. Even if you later find you should switch, you'll have a much better idea what you need what you don't need, and it's not that much trouble to learn the next one. Done. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Grammostola Rosea wrote: I found this: http://supercollider.sourceforge.net/wiki/index.php/Systems_interfacing_wit… Also some possibilities with faust..

rosea grammostola wrote: supercollider seems like a no go pd has some possibilitites, the easiest would be to make the http://www-crca.ucsd.edu/~jsarlo/pdvst/ work on linux. I mailed the author, but didn't get a reply back just yet. csound has csoundvst, which should work, just have to figure out where I can download it (there seems to be no official releases, or something)... So csound seems closest... -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

It's probably healthy for linux audio to have some people thinking that way :) Devs usually code for fun, aren't paid, have limited time and a project already running. IIRC the hammond thread led to connie and the bagpipe thread recieved at least a fiew responses. No revolution but something. Apart from plugins there is Jack. Maybe the people not bothering about the plugin situation are happy using Jack apps and value the flexibility of e.g. pd or ams more than fancy instrument plugins. A matter of ambitions and taste. There are no big commercial players in the world of linux audio, so there are no entities equipped with the interest and resources to serve professionals with complete solutions. (Well, for plain multitrack recording there is 64studio/Ardour, I'd call it rather feature-complete.) Linux appears to be good at well designed (thus in this respect professional-friendly) infrastructures to build upon, and less good at serving end users in the first place. LV2 is not yet mature so it will take some time and/or donations until... d

If you are going to put velocity curves on the controller itself then you are going to lose responsiveness, no? Midi only supports a 7 bit velocity: if the curve is on the controller then a non-linear curve implies some of the 127 values have to be duplicated and some will not be used - that implies you have lost sensitivity in the touch response. If is far wiser to to pass a full linear resolution to the application, let it convert that into an internal curve that generates floats and can thus provide a far smoother curve. It also makes programming the controller simpler as it will be able to avoid implementing a feature that the app/softsynth has to do anyway and can probably do better than MIDI. Regards, nick. "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer Date: Sun, 4 Oct 2009 08:50:48 +0200 From: f.rech(a)yahoo.fr To: rosea.grammostola(a)gmail.com CC: linux-audio-user(a)lists.linuxaudio.org Subject: Re: [LAU] From audio synthesis environment to plugin rosea grammostola a écrit : Atte Andre Jensen wrote: rosea grammostola wrote: @ Atte, Any results from your research yet? supercollider seems like a no go pd has some possibilitites, the easiest would be to make the http://www-crca.ucsd.edu/~jsarlo/pdvst/ work on linux. I mailed the author, but didn't get a reply back just yet. csound has csoundvst, which should work, just have to figure out where I can download it (there seems to be no official releases, or something)... So csound seems closest... A little OT, but when you talk about VST (hardware) hosts (see other thread), you got a lot of replies and also comments that we don't need VST cause we have enough plugins... But you don't get many response, when you actually have a idea to improve the plugin situation in a GPL manner... Maybe people think the plugin situation on Linux doesn't have to be improved, but I can't believe (sorry about that) a zynaddsubfx (which acts pretty unstable with jack and have clicks and pops) and plugins like hexter can satisfy the needs of, let's call them professionals. \r A little delayed, but like to know : What Linux applis are you using to have sound for "replace" : -piano -electric piano -trompet -sax -trombone -drums -violin -etc ? Personnaly, don't use VST, but orchestration is really reduced in terms of instruments, let say it's a good opportunity to improve my guitar and bass play ! Thanks for answers, Fred _________________________________________________________________ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…

On Sun, 04 Oct 2009 08:50:48 +0200 fred &lt;f.rech(a)yahoo.fr&gt; wrote: The issue is VST which is controlled by Steinberg and will always be at least legal trouble. Look at the VST situation: There are windows VSTs, they always require wine and in addition to that the Steinberg VST SDK, which is not redistributable or vestige. There are linux VSTs, which always require the non-redistributable Steinberg VST SDK. Wine and audio itself is a PITA, having to rely on something that can only be obtained from a company like Steinberg is not only annoying, because ever user has to obtain the VST SDK from them, but also dangerous, because they control it. Nobody will have anything against the improvement of the situation, but VST just isn't the way to go, mainly for above mentioned reasons. There are arguments about whether lv2 is, but I see indication that it can be, have a look at the invada plugins (http://www.invadarecords.com/Downloads.php?ID=00000264) . They were windows VST, then got ported to ladspa and then to LV2. The LV2 version even sports graphical GUIs. The most professional orchestration people I know use linuxsampler, have a look at openoctave.org. Regards, Philipp

rosea grammostola wrote: Still somewhat OT but in the vein; My recent decisions to take my studio to a primary focus of using Linux Audio were only with hesitation because of VST availability...in this case, in a 64 bit environment. My single requirement with a VST instrument is to have a 128 instrument GM or GM2 softsynth, similar to Roland Virtual Canvas. The only thing that comes close to filling this roll is fluidsynth with soundfonts. I am yet to find sound fonts that suit me and compare. Back on topic, the only benefit to me with a plugin that could do this, or any other function for that matter, is if it uses less CPU or machine resources as a result. The way that audio devices and apps / plugins lay out in the jack patching system via Qjackctl or jack rack for example, make almost anything routable to anything. Currently, I cant see the benefit in this case to having a standalone application as opposed to a plugin from a user perspective. I dont disagree that users who want specific things in Linux audio should be willing to encourage a developer by paying / contributing something towards it. The Ardour development model seems to be forging the path here with making what they develop of their own accord available for free...but if you want something special developed ´right now´, kick in some funds for the dev to swing his focus to that. Nothing I ever obtained in life that was worthwhile, came quickly, easily, or ´free´! Thanks, Russell

On Sun, 04 Oct 2009 18:38:02 +0200 rosea grammostola &lt;rosea.grammostola(a)gmail.com&gt; wrote: I don't remember saying anything about free. Steinberg controls the technology and distribution of an essential part of the technology. They could, at any time, remove the SDK from their website and there would be no legal way for a user to obtain the SDK. And you're apparently still ignoring faust for some reason.