21 Jan
2007
21 Jan
'07
3:29 p.m.
I never got this working with just python. Segfaulted.
Now it is using llvm in addition. The llvm on Debian Sid is not good enough so
one must download sources and go to it. However, this does not compile like
other ./configure. make, make install.
Follow their instructions. Llvm itself will compile and install just fine. Now
go to the llvm-gcc front end (they recommend using binaries but there are
none for Debian and Debian's llvm is not recent enought so ...)
The compile dies looking for GCC_4.2.0 as required by libstdc++. This
libstdc++ is off Debian Sid but gcc there is not up to 4.2.0. So how might
this "require" it. Anyone succeded with this thing?
21 Jan
21 Jan
4:27 p.m.
On Sun Jan 21, 2007 at 09:45:54PM +0200, David Baron wrote:
I never got this working with just python.
Segfaulted.
Now it is using llvm in addition. The llvm on Debian Sid is not good enough so
one must download sources and go to it. However, this does not compile like
other ./configure. make, make install.
Follow their instructions. Llvm itself will compile and install just fine. Now
go to the llvm-gcc front end (they recommend using binaries but there are
none for Debian and Debian's llvm is not recent enought so ...)
The compile dies looking for GCC_4.2.0 as required by libstdc++. This
libstdc++ is off Debian Sid but gcc there is not up to 4.2.0. So how might
this "require" it. Anyone succeded with this thing?
here on gentoo 2006.1-amd64, i got llvm proper to copmile out of the box. the -gcc one is
more anoying, eventually figuring the right LLVMOBJDIR and other stuff (also, note it will
fail during compile if you used relative paths), it started byilding. but then only
libiberty was created. so i tried make again, with the 'bootstrap' option. this
time it compiled for about 10 minutes then errored out. release versions..
cant wait to try aldrin!
22 Jan
22 Jan
7:18 a.m.
On Sun, 21 Jan 2007 16:27:43 -0500
carmen <_(a)whats-your.name> wrote:
On Sun Jan 21, 2007 at 09:45:54PM +0200, David Baron
wrote:
try
scons LUNAR="False" configure
HTH
Tom
I never got this working with just python.
Segfaulted.
Now it is using llvm in addition. The llvm on Debian Sid is not
good enough so one must download sources and go to it. However,
this does not compile like other ./configure. make, make install.
Follow their instructions. Llvm itself will compile and install
just fine. Now go to the llvm-gcc front end (they recommend using
binaries but there are none for Debian and Debian's llvm is not
recent enought so ...)
The compile dies looking for GCC_4.2.0 as required by libstdc++.
This libstdc++ is off Debian Sid but gcc there is not up to 4.2.0.
So how might this "require" it. Anyone succeded with this thing?
here on gentoo 2006.1-amd64, i got llvm proper to copmile out of the
box. the -gcc one is more anoying, eventually figuring the right
LLVMOBJDIR and other stuff (also, note it will fail during compile if
you used relative paths), it started byilding. but then only
libiberty was created. so i tried make again, with the 'bootstrap'
option. this time it compiled for about 10 minutes then errored out.
release versions..
cant wait to try aldrin! 
7:48 a.m.
Thomas Kuther wrote:
Hmm...I still get this on Ubuntu Edgy:
$ aldrin
using wxPython 2.6
Traceback (most recent call last):
File "/usr/local/bin/aldrin", line 6, in ?
aldrin.run(sys.argv)
File "/usr/local/bin/../share/aldrin/__init__.py", line 28, in run
import main
File "/usr/local/bin/../share/aldrin/main.py", line 32, in ?
from utils import format_time, ticks_to_time, prepstr, linear2db,
filepath, is_debug
File "/usr/local/bin/../share/aldrin/utils.py", line 26, in ?
import time, sys, math, os, zzub, imp
File "/usr/local/bin/../share/aldrin/zzub.py", line 22, in ?
import libzzub
File "/usr/local/bin/../share/aldrin/libzzub.py", line 4, in ?
from pylibzzub import *
File "/usr/local/bin/../share/aldrin/pylibzzub.py", line 317, in ?
libzzub = dlopen('zzub')
File "/usr/local/bin/../share/aldrin/procwrap.py", line 35, in dlopen
import library
File "/usr/local/bin/../share/aldrin/library.py", line 27, in ?
from utils import filepath
ImportError: cannot import name filepath
Any ideas..?
--
Ringheims Auto - Fri musikk for bilstereo!
http://ringheimsauto.org
cant wait to
try aldrin!
try
scons LUNAR="False" configure 
8:29 a.m.
On Mon, 2007-01-22 at 13:48 +0100, Johannes Mario Ringheim wrote:
File
"/usr/local/bin/../share/aldrin/zzub.py", line 22, in ?
please clean your tree. there should be no
zzub.py/libzzub.py/pylibzzub.py in aldrins directory.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
8:47 a.m.
On Mon, 2007-01-22 at 13:18 +0100, Thomas Kuther wrote:
scons LUNAR="False" configure
which will turn off all the new plugins (and future ones).
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
9:41 a.m.
On Mon, 22 Jan 2007 14:32:08 +0100
Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Mon, 2007-01-22 at 13:18 +0100, Thomas Kuther
wrote:
Currently trying to ebuild llvm for the Gentoo proaudio overlay, but
that might get hard - gcc-4.1.1 stable here.
That's really a very very heavy depency, almost unacceptable.
I understand that Aldrin w/o lunar, ladspa, dssi or anything is
pretty pointless, right?
Poor, i already see me doing a
'svn del media-sound/aldrin media-libs/libzzub' and gone it will be.
Let's see.
scons LUNAR="False" configure
which will turn off all the new plugins (and future ones).
9:58 a.m.
On Mon, 2007-01-22 at 15:41 +0100, Thomas Kuther wrote:
I understand that Aldrin w/o lunar, ladspa, dssi or
anything is
pretty pointless, right?
actually, ladspa and dssi were not meant to be supported. i did the
wrappers only for fun, in fact i think it's a terrible idea to have them
at all.
lunar is important, and llvm is a heavy dependency, i agree. perhaps i
can swap llvm for gcc, which everybody should have...
if you are interested in the reason why llvm is included at all, i can
perhaps explain a little.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
10:16 a.m.
On Mon, 22 Jan 2007 15:58:26 +0100
Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Mon, 2007-01-22 at 15:41 +0100, Thomas Kuther
wrote:
Yes, I (and maybe others) would be interested. I never heard of it
before and am just starting to see what it is good for.
Currently all i know about it is that it tends to cause massive
headaches for packagers and others trying to compile it :)
I understand that Aldrin w/o lunar, ladspa, dssi
or anything is
pretty pointless, right?
actually, ladspa and dssi were not meant to be supported. i did the
wrappers only for fun, in fact i think it's a terrible idea to have
them at all.
lunar is important, and llvm is a heavy dependency, i agree. perhaps i
can swap llvm for gcc, which everybody should have...
if you are interested in the reason why llvm is included at all, i can
perhaps explain a little.
10:34 a.m.
Thomas Kuther <gimpel(a)sonnenkinder.org> schrieb:
On Mon, 22 Jan 2007 15:58:26 +0100
Leonard Ritter <contact(a)leonard-ritter.com> wrote:
There isn't any llvm package on SuSE so I have to package llvm to? It is
a little bit overkill for another sequenzer. For the moment i keep
aldrin-0.8 and libzzub-0.1.
On Mon, 2007-01-22 at 15:41 +0100, Thomas Kuther
wrote:
Yes, I (and maybe others) would be interested. I never heard of it
before and am just starting to see what it is good for.
Currently all i know about it is that it tends to cause massive
headaches for packagers and others trying to compile it :)
I understand that Aldrin w/o lunar, ladspa, dssi
or anything is
pretty pointless, right?
actually, ladspa and dssi were not meant to be supported. i did the
wrappers only for fun, in fact i think it's a terrible idea to have
them at all.
lunar is important, and llvm is a heavy dependency, i agree.
perhaps i can swap llvm for gcc, which everybody should have...
if you are interested in the reason why llvm is included at all, i
can perhaps explain a little.
11:04 a.m.
New subject: [linux-audio-user] Aldrin 0.9 and llvm (what it is about)
On Mon, 2007-01-22 at 16:16 +0100, Thomas Kuther wrote:
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
Yes, I (and maybe others) would be interested. I never
heard of it
before and am just starting to see what it is good for.
In my 7 years of experience using Buzz, I noticed that often there was a
big hassle involved with sharing (often quite exotic) dsp plugins.
Downloading a song for Buzz is usually not enough, you also require the
machines associated with it, and until you get everything running, time
passes.
Lunar was designed to solve that problem by shipping sources and
precompiled LLVM bytecode per plugin in each song, for all plugins
required. Another user, regardless of platform and operating system,
would then be able to open that song without having to acquire any
additional dependencies. This way, songs saved as ccm modules could be
shared back and forth without any additional dependencies, allowing
quick collaboration.
Even if plugins get updated, old songs would still carry all information
neccessary to get them working. Legacy code would always be connected to
the data that needs it.
LLVM serves as a JIT-compiler, loading and translating the LLVM bytecode
on runtime. LLVM-GCC is used to translate C++ code to LLVM bytecode.
LLVM is currently being used by Apple to optimize their OpenGL pipeline,
and considered a possible new default backend for the GNU compiler
suite.
Currently all i know about it is that it tends to cause massive
headaches for packagers and others trying to compile it :)
LLVM is top notch bleeding edge stuff, and this is the first application
that requires it. I could, alternatively, resort to shipping sources in
songs only, and use GCC locally to compile on demand. However that
approach would bring up issues related to sandboxing the code, and only
languages supported by GCC could be used (where with LLVM, the compiler
frontend does not matter).
12:32 p.m.
New subject: [linux-audio-user] Aldrin 0.9 and llvm (what it is about)
On Mon, 22 Jan 2007 17:00:42 +0100
Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Mon, 2007-01-22 at 16:16 +0100, Thomas Kuther
wrote:
Thanks very much for the explanation. Also reading llvm.org a bit and
it seems like a good thing to have regarding optimizations.
Regarding my process for llvm-gcc(4) and llvm Gentoo ebuilds.. I'm
getting there slowly :)
Might have been much easier to use the binary builds, but well,
Gentoo.. "use the source if it's available" :)
Regards,
Tom
Yes, I (and maybe others) would be interested. I
never heard of it
before and am just starting to see what it is good for.
In my 7 years of experience using Buzz, I noticed that often there
was a big hassle involved with sharing (often quite exotic) dsp
plugins. Downloading a song for Buzz is usually not enough, you also
require the machines associated with it, and until you get everything
running, time passes.
Lunar was designed to solve that problem by shipping sources and
precompiled LLVM bytecode per plugin in each song, for all plugins
required. Another user, regardless of platform and operating system,
would then be able to open that song without having to acquire any
additional dependencies. This way, songs saved as ccm modules could be
shared back and forth without any additional dependencies, allowing
quick collaboration.
Even if plugins get updated, old songs would still carry all
information neccessary to get them working. Legacy code would always
be connected to the data that needs it.
LLVM serves as a JIT-compiler, loading and translating the LLVM
bytecode on runtime. LLVM-GCC is used to translate C++ code to LLVM
bytecode.
LLVM is currently being used by Apple to optimize their OpenGL
pipeline, and considered a possible new default backend for the GNU
compiler suite.
Currently all i know about it is that it tends to cause massive
headaches for packagers and others trying to compile it :)
LLVM is top notch bleeding edge stuff, and this is the first
application that requires it. I could, alternatively, resort to
shipping sources in songs only, and use GCC locally to compile on
demand. However that approach would bring up issues related to
sandboxing the code, and only languages supported by GCC could be
used (where with LLVM, the compiler frontend does not matter).
21 Jan
21 Jan
6:52 p.m.
On Sun, 2007-01-21 at 21:45 +0200, David Baron wrote:
I never got this working with just python. Segfaulted.
you can run aldrin off the unwrapped package. there is an "aldrindebug"
in the bin directory that starts aldrin in gdb. enter "run", when the
segfault happens, enter "bt", and send me the output.
please also list your machine specs... cpu info, mostly.
Now it is using llvm in addition. The llvm on Debian
Sid is not good enough so
one must download sources and go to it. However, this does not compile like
other ./configure. make, make install.
yes, unfortunately. it totally sucks, i agree.
Follow their instructions. Llvm itself will compile
and install just fine. Now
go to the llvm-gcc front end (they recommend using binaries but there are
none for Debian and Debian's llvm is not recent enought so ...)
try some of the prepackaged binaries. i used the redhat ones with
ubuntu.
never managed to build llvm-gcc itself.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
6337
days inactive
6338
days old
linux-audio-user@lists.linuxaudio.org
12 comments
6 participants
participants (6)
-
carmen -
David Baron -
Johannes Mario Ringheim -
Leonard Ritter -
Oliver Bengs -
Thomas Kuther