On Sat, Dec 11, 2010 at 08:06:26PM +0300, Oleg Ivanenko wrote:
> So, zita-at1 WAS installed from "source-dir"
> /mnt/music/src/audio/fons/zita-at1-0.2.0/source
Indeed... Since the build doesn't produce any information,
the only way seems to run zita-at1 from gdb and get a stack
trace.
Is there anything unusual about your system/X11/Jack ?
Ciao,
--
FA
There are three of them, and Alleline.
On Sat, Dec 11, 2010 at 07:07:36PM +0300, Oleg Ivanenko wrote:
> What am I doing wrong?
> --
> Truly yours, Oleg Ivanenko aka Ash
> [if it wasn't so sad, it would be funny]
You must do a 'make install'. It will not run from the
build directory.
Ciao,
--
FA
There are three of them, and Alleline.
>
>
> Message: 8
> Date: Fri, 10 Dec 2010 22:01:50 +0000
> From: Victor Lazzarini <Victor.Lazzarini(a)nuim.ie>
> Subject: Re: [LAD] Project proposition: llvm based dsp engine
> To: "linux-audio-dev(a)lists.linuxaudio.org >> The Linux Audio
> Developers' Mailing List" <linux-audio-dev(a)lists.linuxaudio.org>
> Message-ID: <EEFBDE7E-30EB-4C1D-87FF-39621F1EC4A8(a)nuim.ie>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed";
> DelSp="yes"
>
> This is all very interesting. One question I had regarding the future
> development of FAUST is whether it will include some sort of scheduler
> so that various faust-coded objects can be instantiated at different
> times, connected together in series, etc.. Then an interpreter could
> be developed with JIT compilation etc.
>
> Or is this more like the idea of combining FAUST with another language
> like pure?
>
> Victor
> On 10 Dec 2010, at 12:28, St?phane Letz wrote:
I would say yes. Faust should stay as the DSP computation stage only.
Stéphane
Le 9 déc. 2010 à 22:17, Maurizio De Cecco a écrit :
> On Thursday12/9/10 2:24 PM, Stéphane Letz wrote:
>
>> By since you have a lot of jMax object coded in C, I guess testing the idea with the current jMax environment should be easy: just compile your jMax objects in LLVM bitcode ad try to "combine" (Link Time Optimization) them with LLVM API.
>
>
> Exactly (well, more or less).
> One interesting point is the control part; it is theoretically possible to get a control patch made of simple objects (things like ints, operators, trigger, if) up to native C speed.
>
> This would require writing objects in a slightly different way.
>
> Anyway, for the moment all this is out of reach, not enough time.
> But you never know :->
>
> Maurizio
Well what could be interesting to share would be something similar to the "FIR" (Faust Intermediate Language) that we are currently designing and implementing.
Basically Faust currently does :
Faust dsp program ==> [BDA (Block Diagram Algebra) evaluation ] ==> Signals ==> FIR loops DAG (Direct Acyclic Graph) ==> C/C++, JAVA, LLVM, (possibly CUDA, OpenCL at some point) backends.
FIR is a imperative like language where a Faust program is represented as a data structure + list of functions (init, buildInterface, compute...). The "compute" function does the actual DSP computation and is currently executing the DSP loops DAG in different modes:
1) vector mode : the loops DAG is simply topologically sorted and compiled in the target language (C/C++, LLVM...). The we hope GCC or ICC auto-vectorization features can do the job to produce SIMD code.
2) OpenMP mode: OpenMP pragmas are inserted at the right place in the DAG to express parallelism (and each loop can possibly be auto-vectorized).
3) Work Stealing Scheduler : the loops DAG is compiled with an "embedded" WSS algorithm (and each loop can possibly be auto-vectorized).
2) and 3) steps are typically expressed as "FIR to FIR" transformations.
It could be possible to let other tools enter the chain before the "FIR loops DAG" step so that to take benefit of all the later steps : FIR to FIR parallelisation, and all available backends. We can even imagine to implement some kind of "inter plug-in" optimizations at the FIR level.
But of course the simplest way to produce this "FIR loops DAG" is... using Faust itself, and "inter plug-in" optimizations are way simpler to handle at the Faust level (basically at the "signal step") . So I don't know if the idea makes sense, but you never know :->
Stéphane
I'm experimenting with lv2_jack_host with Gabriel's excellent
composite loaded, and have a general question.
Is lv2_jack_host, from a terminal, jack-sessionable?
Or, if this isn't viable, if any loaded plugins are jack-session
capable, can lv2_jack_host save a "state", enabling any jack-session
capable plugins to have their state re-instated, when a jack session
is started/restarted?
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
An update of zita-at1 is available at the usual place:
<http://www.kokkinizita.net/linuxaudio/downloads>.
Changes:
* The resampler now uses cubic interpolation (at twice
the sample rate for 44.1 and 48 kHz), giving even
cleaner output.
* The offset control now has 400 steps of exactly 1
cent (1/100 semitone) each, and displays the set
value when touched. Default mousewheel step is 10
cents, 1 cent with Shift pressed.
Enjoy !
--
FA
There are three of them, and Alleline.
On Fri, Dec 10, 2010 at 03:26:20PM -0200, Fabio wrote:
> let's se if the dev responds (i don't know nothing about programing)
Here I am.
Not having textual input is choice I made and I'll stick to it.
What I can easily add is a display of the current value if you
touch 'Offset', just as for 'Tuning'. I just didn't think it
would be useful and that you'd normally adjust this 'by ear'.
BTW there's a small bug in the 'Offset' control, it has 330
steps instead of the intended 400.
Expect a new release somewhere this WE.
Ciao,
--
FA
There are three of them, and Alleline.
tuxguitar has java support for guitar pro files, so the format is
understood, I'm wondering if anyone ever ran across a c/c++ library for
reading them? I found ptparser for power tab, but most of my tab is in
gp3/4/5 format, and I'd like to be able to write some code dealing with gp
stuff, without having to write a whole lib to read them.
Thanks,
Nathanael
Please post this invitation to LAD - LAD NAMM 2011 Trinity Audio Group /
Indamixx
Hi All,
The Linux Audio community is a 6 year blessing to our existence.
We would like to invite 5-7 at large attendees of Linux Audio Developers as
our guest at NAMM 2011.
Our 5-7 passes for NAMM are full vendor passes. Anyone in the area (Los
Angeles) or who would like to attend globally and has the funds to buy
airfare I will work with to get hotel accommodations at a super discounted
rate as to not pinch the wallet.
Deadline for emailing me you are interested in December 14th as the 15th is
the day I must submit our final vendor attendee list.
my email is ronaldjstewart(a)gmail.com
here is the NAMM website:
http://www.namm.org/thenammshow/2011
Thank you so much LAD!
Ronald Stewart
Creative Director
Trinity Audio Group Inc.
9854 National Blvd. #322
Los Angeles CA 90034
310-733-9285
ronaldjstewart(a)gmail.com
Hello lists :)
First, an introduction. Within the context of this mail I'm
representing re-lab -- a small project [1] that does a dirty job
developers usually try to avoid -- reverse-engineering file formats
that have no publicly available specs. Our primary goal is helping dev
teams and therefore end-users to support legacy data.
We started with Corel DRAW back in 2007 (supported by Inkscape, sK1
and UniConvertor now), continued with painting dynamics in Photoshop
brushes (supported by Krita in SVN trunk) and Photoshop gradients
(supported by SwatchBooker), and now we arrive to audio domain.
A while ago we asked Ardour team if they wanted some file formats
reverse-engineered. Paul named a couple of such file formats,
including REX2 audio loops [2].
Since we are (at least pretend to be) nice guys, we started with
mailing Propellerhead, but they never replied (only to be expected,
given their track record re open source teams). Well, something had to
be done about that, eh? So we started looking into things.
Initial version of Python scripts that parse .rx2 files and dump stuff
to stdout is already available [3]. This is exactly what deliver in
the end: Python scripts for parsing and a specification that explains
what every chunk does.
Now here is what we need. All we have right now is a bunch of .rx2
files that I got with my Focusrite Saffire Pro24 and bundled software.
It's good for a start, but for proper r-e we need introducing small
changes to files and seeing what's changed. So we need someone with a
licensed copy of ReCycle and some spare time on his/her hands to help
us figuring things out.
Demo version of ReCycle works fine in WINE, but saving and loading
arbitrary files is impossible. We really do not want dealing with
pirated copies, because, again, we do our best to be nice guys.
And since we do it not just for fun, but for actual results, we'd be
glad if developers of other applications (FreeCycle and Smasher are
the first I can think of) implemented support for REX2.
Coincidentally we are also interested in people who are good at audio
compression algorithms. *cough* Monty *cough* :)
By the way, usually I don't read both l-a-u and l-a-d lists, so after
a while (a week maybe) I'll turn off delivery of mails, which means
you probably want using Reply to All button in your mail client of
choice.
[1] http://gitorious.org/re-lab/
[2] http://en.wikipedia.org/wiki/REX2
[3] http://gitorious.org/re-lab/audio
Alexandre Prokoudine
http://libregraphicsworld.org