[CLAM] Re: CLAM questions

[Pau Arumi]

(I'm CCing this private thread to the public clam list. It may be 
interesting for others)

Hi Christopher,
some advice using CLAM:

For your needs, I recommend start playing with Network Editor and the 
Prototyped apps. But you'll see that for Mac is not so easy right now.

Rappid and Spectral Delay are old and discontinued projects that need 
very primitive versions of CLAM (maybe 0.6 or so), I don't recommend you 
to try to compile these.
However with Network Editor and Prototyper you can accomplish similar 
things in a more black-box (so, quick) way.
(Implementing a Spectral Delay editing CLAM networks should be really 
straightforwards, without considering the widgets ).

As you saw, we are primarily developing in Linux. So I would say that if 
you want to take the most of core developers support, use Linux.
However, developing with testfarm (linked at the clam web) we are 
reaching the goal of developing all platforms with the same care.
For example, we've been able to push the Windows platform a lot thanks 
to that.
To be more concrete, testfarm is constatnly waiting for a new commits, 
when awakes it doew auto-tests  and finally uploads the apps installers 
to the web.

The sad thing is that by organizational reasons at the university, we've 
lost access to the Mac box that we used as testfarm client, so 
installers (dmgs) for the forthcoming release won't be available.
However, this is just temporal. Now that we took Windows up front, the 
turn is for Mac OSX. And for sure it will be much easier!

The .dmgs of NetworkEditor you have installed corresponds to version 0.3 
(clam 0.91)
The new Network Editor 0.4 version (clam 0.95), based on Qt4 have a 
radically reworked UI, much more usable and powerful in terms of 
processings available.
If you are brave, try compiling the code (it takes installing external 
libs and probably adjusting our SConstruct a little, but would help us a 
lot!).
Else, wait a little (2 weeks) till Mac catches up and, meanwhile, try 
binaries in Windows or Linux (ubuntu edgy or debian sid)

Pau



En/na CHRISTOPHER TIGNOR ha escrit:
> Hi Pau,
>
> Thanks so much.  Just got began installing the CLAM libraries onto my OS
> 10.39 machine, though I'm considering another OS for the actual project
> development, perhaps an audio-optimized Linux Kernel distribution - I
> believe there's at least one out there for this.  As mentioned I'll be
> looking into dedicated device options too as performance and reliability in
> a live context is paramount.  I'll examine your Spectral Delay and Rapid
> apps first in this regard on my laptop and see how they fair.
>
> I'll check out Jack and the like and of course I am more than happy to
> contribute my re-useable efforts back into the framework.  Having spent some
> years managing software teams I can promise it will be clean and
> developer-friendly!
>
> Thanks so much,
>
> C>T>
>
> On 12/4/06 3:04 PM, "Pau Arumi" <parumi at iua.upf.edu> wrote:
>
>   
>> Hello Christopher,
>> the CLAM team would be delighted if you would use CLAM as
>> you say ! And incorporate your output to the framework, of course.
>>
>> En/na CHRISTOPHER TIGNOR ha escrit:
>>     
>>> Dear Mr. Arumi,
>>>
>>> My name is Christopher Tignor, a composer and software architect living in
>>> Brooklyn, NY.  My musical work with computers has involved the creation and
>>> performance of live acoustic processing instruments whose sound is derived
>>> from the live performances of other accompanying, acoustic musicians,
>>> working largely with both JSyn and also, historically, with Max/Msp.  These
>>> software projects often grow into comprehensive code-sets.
>>>
>>> I am beginning a new development cycle on a new system and am interested in
>>> the CLAM framework.  A few questions:
>>>
>>> 1) Do you have any anticipated timeframe for a stable 1.0 release.  I am
>>> hesitant to use software that has a leading 0 before its version.
>>>
>>>   
>>>       
>> You are lucky, CLAM 1.0 is due in a very short time: Before the end of
>> this year.
>> (actually today we are finishing 0.95 and we are in a development sprint )
>> However, numbering is always something very subjective.
>> For sure CLAM 1.0 will not be LaTeX.
>>
>>     
>>> 2) Based on the "live instrument" nature of my work, system latency and
>>> run-time performance can be key factors.  How do similar software projects
>>> written using the CLAM dsp libraries fair under such conditions?  Am I
>>> correct in assuming CLAM implements a vector based dsp processing paradigm
>>> with adjustable signal vector sizes (As opposed to STK's sample based
>>> processing)?
>>>   
>>>       
>> It is explained in the CLAM design patterns
>> http://hillside.net/plop/2006/Papers/Library/audioPatterns_20060809.pdf
>> However this approach does not inherently add latency if it is not needed.
>>
>>     
>>> 3) My personal system runs OS X (I realize this isn't your primary
>>> development environment) using the Metric Halo Mobile I/O 2882 audio
>>> interface.  How does CLAM fair with this OS and A-D converter? JSyn, which
>>> uses PortAudio, seems to be unable to use my MIO interface in any sampling
>>> rate other than 88.2)
>>>
>>>   
>>>       
>> Can you run Ardour, sooperlooper or any jack application with your hardware?
>> CLAM uses PortAudio or JACK as backend. And JACK can interface with any
>> hardware that CoreAudio recognizes.
>>     
>>> 4) Related: Is an underlying C library such as PortAudio used for such
>>> low-level dsp interaction or is yours homegrown?
>>>
>>>   
>>>       
>> Well, we have a homegrown (blocking) layer to interact with Linux Alsa
>> and Windows Direct X. Now, for many reasons, we are dropping out this
>> layer in favor of using PortAudio (and JACK)
>>     
>>> 5) I am becoming interested in developing my dsp instruments as embedded
>>> systems into custom-built dedicated devices, as opposed to personal
>>> computers.  Have you had any experience with this using CLAM and if so how
>>> has it gone?
>>>
>>>   
>>>       
>> Some years ago YAMAHA did an embeded implementation of a CLAM real-time
>> application. But I don't know to which extend they reused the code.
>> I guess the crutial point here is if those dedicated devices support
>> floating point processing or only integer based.
>>     
>>> Thanks for the taking the time to answer all these inquiries.
>>>   
>>>       
>> You welcome!  Hopefully we keep hearing from you :-)
>>
>> Pau
>>     
>
>
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.