hi,
The buzztard team has released version 0.5.0 "crown of thorns" of its
buzz-alike music composer. All modules got extensive improvements over the last
release from almost a year ago. Give it a try, join hacking and report bugs.
bml
--------------------------------------------------------------------------------
Split the api into library and instance api. Lots of code and build cleanups.
bsl
--------------------------------------------------------------------------------
Several bug fixes and better compatibility.
buzztard
--------------------------------------------------------------------------------
Rewrite of internal pipeline management. One can now play partially connected
songs, and add/remove plugins while playing. Buzztard can play notes while
editing. More robust saving of songs. Lots of bugfixes and UI improvements.
Better user-guide including three small tutorials. Initial support for python
and javascript via gobject introspection.
gst-buzztard
--------------------------------------------------------------------------------
Lots of improvements in the buzzmachine wrapper. Buzz index support for
categories. Make machines live-playable. More resource efficient.
project-page: http://www.buzztard.org
screenshots: http://www.buzztard.org/index.php/Screenshots
downloads : http://sourceforge.net/project/showfiles.php?group_id=55124
buzztard core developer team
--
http://www.buzztard.org
Hi folks, I have done any linux audio dev in a few years, and wondering
what I should be using for a simple cross-platform real time capable
python library for handling midi. I was previously using portmidi, but
noticed there has been more recent releases of rtmidi. Any advice
appreciated.
thanks
Iain
Hello everyone!
I have a problem and I'm not sure how to solve it in an optimal way. I have
several threads running.
1. An input thread (computer-keyboard/mouse)
2. An output thread (monitor other devices0
3. A working thread (the engine)
Now I wondered, what is the most efficient way to write the loops for the
input and output threads in a way, that they are always ready to accept
something coming.
I thought about something with signals, which is fine, as far as the output
is concerned, but the input comes from the user and only the device gets it
coming first and it can't really send a signal?
Any tipps, good guide or constructs, which have proven to be efficient?
Please/
Best regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
On Fri, Aug 28, 2009 at 03:31:53AM +0200, hollunder(a)gmx.at wrote:
> It will never be run from there, the user is the packager in the sense
> that the user runs the script and thus creates the package that he can
> install afterwards. We, as packagers, just write a part of the script,
> the user can modify this script to her liking or just run it, which in
> turn builds the binaries and creates the package on the users system.
>
> Sorry if we were unclear about that, but we were talking about AUR,
> the arch user repository where only scripts are supplied that help the
> user to build a package. AUR doesn't provide binaries as such (except
> for rare cases). The same scripts are used for the official
> repositories but there they provide binaries and the scripts are
> optional.
>
> I hope it's somewhat clearer now, sorry for the confusion.
Yes, thanks.
I'm perfectly willing to prefix $(DESTDIR) to any install directories
if that is all that's required.
But while I can clearly see the use and even necessity for $DESTIR
for someone who is creating a binary package from a source package
(without having to really install that package locally), what on
earth is the purpose of forcing someone who installs from source
to go via such an intermediate step ? If the Makefile provides a
working 'make install' why complicate it ? And more pertinently,
how am I supposed to provide support for users who do such things ?
If I release a source package, and someone has a problem compiling
or installing it, I'd be happy to help. But not if the installation
procedure has been modified for no good reason - I could probably
go along with some changes, but where does that end ?
The web page about $DESTDIR you pointed says that one of the uses
would be to allow a user without root privileges to install in
some local dir (s)he has access to. But it contradicts that same
use by declaring that 'embedded file names will not be modified'.
Which in some cases will mean that the application will not run.
To install into a e.g. a home directory a user would have to modify
$PREFIX, not $DESTDIR.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
After reading extensively on digital filters used as crossovers,
I just finished implementing a digital LR-4 crossover filter using 2
chained butterworths 2 pole q=1/sqrt(2).
I used the bilinear transform method to calculate the coefficients of
the butterworth filter and chained 2 of them together to make the
Linkwitz-Riley.
I wrote a simple calf plugin using this dsp. The frequency response
curve of the output shows accurate 24dB/octave rolloff with white
noise fed into the filter, however the highpass filter curve shows
considerable noise at low frequencies (under 40Hz).
Should I be using a different algorithm? I read somewhere that
"biquad" is a good method, but I have no idea how to do it.
Regards,
Damien
Hi,
I've received a complaint about VMPK not seeing other application's MIDI ports
in the internal connections dialog. Among others, it doesn't list
LinuxSampler ports. This isn't usually a big problem, because it is still
possible to make the subscription using a connection manager like aconnect or
qjackctl.
Anyway, the problem is that VMPK (using RtMIDI functions) enumerates and
filters the existing ALSA sequencer ports in the system having the port type
flag SND_SEQ_PORT_TYPE_MIDI_GENERIC, that means "This port understands MIDI
messages." according to the alsa library documentation:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_port.html#g43e52c…
This is the same policy used for instance by aplaymidi, from alsa-utils. If
you execute "aplaymidi --list", it doesn't show linuxsampler either.
Please: can you add SND_SEQ_PORT_TYPE_MIDI_GENERIC to the sequencer ports of
your synths, if the ports understand MIDI messages and are supposed to be
subscribed by players or other applications?
In addition, there are other interesting flags defined in the ALSA library
that could be applied also to LinuxSampler, for instance:
SND_SEQ_PORT_TYPE_SYNTHESIZER.
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_port.html#ge67062…
Regards,
Pedro
Patrick Shirkey:
>
> Hi,
>
> For those of you who are not subscribed to LAU, yesterday I had time to
> run a test to see how easy and stable it was to run pulseaudio with jack
> on Fedora 11.
>
> I had a few problems at first but after upgrading to pulseaudio-0.9.16
> (latest dev version) I was able to successfully connect Pulseaudio to
> Jack and play tracks with Totem. It was still a little unstable as I was
> able to bring pulse down a few times while using the
> gnome-volume-control applet. However jack was not affected by pulse dying.
>
> I did this on a standard Fedora kernel with a 2 core intel and 4 GB RAM.
> My system load without any audio playing it was around 10%. While
> playing a track with Totem through PA into Jack was around 20%. This
> could be due to the visuals that were running at the same time. I was
> able to listen to a complete 30 minute dj mix without any dropouts while
> still using my system as usual. I am going to run a full day test of
> audio playback today.
>
Which kernel are you running, and are you using a 32 or 64 bit
distribution?
I'm using the 32 bit distribution of fedora 11 with the latest
fedora PAE kernel. The cpu is a 4 core intel i7, 6 GB ram.
I haven't had any problems at all with pulseaudio/jack (only using
the packages provided by fedora), and I'm a bit surprised about
your post. But I haven't tried totem, I'll do when I get home.
Hi everyone,
perhaps one of you might have already seen this issue and will
know what is the best solution.
My problem is that one of the headers in the VST SDK2.4, aeffect.h,
has a macro, VSTCALLBACK, which in gcc will be defined
as __cdecl . This is not recognised by the compiler, thus preventing
me from using that header (to build a plugin).
My solution was to forcibly undefine __GNUC__ so that the macro
gets a blank definition.
However, I am not sure this is the best way out; I am wondering whether
the calling convention will break the plugin, since the host might be
expecting __cdecl and it will not be getting it.
Perhaps someone else would have a different solution.
Regards
Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth
On Wed, 26 Aug 2009 23:42:12 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
> On Wed, Aug 26, 2009 at 11:09:27PM +0200, Renato wrote:
>
> > Hello, I've packaged this plugin for Archlinux, it's now in the AUR
>
> Thanks ! It's a bit unfortunate you acted so quickly - the plugin
> is still in a 'beta' stage and following releases could well be
> incompatible. This is no big deal for people who install from
> source, but could generate some trouble for the others.
>
> > btw it would be good if in 'make install' the necessary files are
> > copied to $(DESTDIR)/pathtowherecopyfiles rather than
> > simply /pathtowherecopyfiles ; this surely makes packaging much
> > easier on Arch
>
> How should this be split up ? AFAIK there's only one place to
> install LADPSA plugins, and the usual /usr or /usr/local
> separation is not used. But I could be wrong about this.
>
Well, I don't know about LADSPA plugins, but the fact is that in Arch
for building from source in a pacman-aware (pacman is Arch's package
manager) manner, you need the DESTDIR option... infact you first
install all the files with the exact same direcotry tree as would
do 'make install' but, instead of in root, in a working directory...
i.e. you do
'make DESTDIR=/pathtotmpdir install'
Then you point pacman to /pathtotmpdir, so he knows what to install and
where on the system and keeps neatly track of it (you can then easily
remove the package).
So for Archers the DESTDIR is important, but on the other hand it's
easy to patch a Makefile if it doesn't have the DESTDIR option, so no
real big problem for now... just a heads up for the future.
> > and also btw, good plugin - I've used it with good results with the
> > settings suggested by Gabriel :)
>
> Fine !
>
> Ciao,
>
ciao,
Renato
