Greetings:
I have a problem with a piece I'm working on in Rosegarden 1.5. I've
appended the text I sent to Chris Cannam, along with his response (I
hope he doesn't mind). Btw, the machine is based on an AMD64 3200+, with
2G RAM and an 80G hard drive. Sound runs through an M-Audio Delta 66.
Distro is 64Studio 2.0.
My questions lead, Chris's replies follow :
>> 2) I've written a piece consisting of six tracks with these specs:
>>
>> Tr.1 (audio) drum loop, repeated, 1 plugin (CAPS plate reverb 2x2)
>> Tr.2 (MIDI) bass part, repeated, uses patch from 8mbgmsfx.sf2
>> soundfont, no fx (part is rendered via QSynth which does have its
>> reverb active)
>> Tr.3 (audio) rhythm guitar loop, repeated, 3 fx (dj EQ mono, CAPS
>> compress, CAPS plate 2x2)
>> Tr.4 (audio) lead guitar, no repeats or copy, 4 fx (CAPS plate 2x2,
>> AmpIV, AM pitch shifter, multiband EQ)
>> Tr.5 (audio) riff loop, copied, 3 fx (dj EQ mono, CAPS compress,
>> CAPS plate 2x2)
>> Tr.6 (audio) another percussion loop, copied, no fx
>>
>> At 120 BPM the piece is 200+ measures long. It plays along
>> swimmingly, but at m. 74 (about two minutes into the piece) the sound
>> cuts out entirely. RG continues to run, but it pops up a message
>> telling me that there's not enough CPU for realtime processing. Up to
>> that point JACK reports approximately 33% CPU usage and no errors,
>> but then it reports 0(1024) for xruns. I don't know what the second
>> number (1024) means to JACK, but it keeps rising (with no sound)
>> until I halt RG.
>
>
That sounds a bit like a plugin denormal problem. Although denormals
are usually less of a problem on AMD64.
The 0(1024) in qjackctl I think means that JACK has reported 1024 xruns
via the reporting API but they haven't been mentioned in the message
log. I don't actually know what causes that. Does CPU usage (as
reported by a plain old CPU usage reporting program) actually peak at
that point?
>> So my question is: Given my machine, should my CPU be topping out in
>> this scenario ?
>
>
Probably not, or at least I wouldn't expect it to suddenly peak if usage
has previously been on the low side.
The only thing RG does that may affect CPU usage drastically during
playback is that it doesn't start running plugins until they actually
have something to work on, and it stops running them if they've fallen
silent for a certain period and have no more input coming up (this is
in contrast to e.g. Ardour which runs plugins all the time during
playback, taking a more strictly correct view).
So, if anyone has anything to add to Chris's assessment, I'd like to
know about it. If the problem is indeed related to denormals, is there a
way to fix it ? Comments and suggestions are most welcome.
Best,
dp
Patrick Shirkey wrote:
> Very cool having so many loops able to play at one time. Beats a Pioneer
> hands down.
A Pioneer what...?
> Is the BCF2000 triggering freewheeling via midi or osc?
Hmmm...I don't actually know ;) I just got the BCF, and haven't figured
out all the possibilities yet. I wrote the XML-config in a "get this up
and running quickly" manner, so I will investigate other options and
hopefully make a proper config file wich I could share with others.
AFAIK it's controlled by midi now, but I will investigate this OSC
option aswell.
If anyone wants my config you can of course give me a note, but I warn
you that it's a bit improvised.
> Once again nicely done. If there was an award for best Linux DJ you would
> be getting my vote this year!
Well, what can I say? Thanks a lot!
I'm hoping to play this thing live during the spring and summer, if only
I could come up with a name for the thing :)
--
Ringheims Auto - Fri musikk for bilstereo!
http://ringheimsauto.org
Can it be done? I mean, chain "preamp plugin + EQ plugin + speaker
plugin" into a single plug-in preset that can be loaded later. Is LASH
the way to go?
Cordially, Ismael
--
Ismael Valladolid Torres m. +34679156321
La media hostia j. ivalladt(a)gmail.com
http://lamediahostia.blogspot.com/
Hi (again)
I'm a little baffled about the fact that jackd reports it expects to use
/tmp, which I imagine should be of type tmpfs. Should I do something
about it (if so, what)?
atte@ajstrup:~$ jackd -V
jackd version 0.102.20 tmpdir /tmp protocol 16
atte@ajstrup:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 19G 9,7G 7,8G 56% /
tmpfs 506M 0 506M 0% /lib/init/rw
udev 10M 88K 10M 1% /dev
tmpfs 506M 0 506M 0% /dev/shm
/dev/hda4 54G 43G 7,6G 86% /mnt/data
/dev/hda1 19G 15G 3,1G 83% /mnt/unstable
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
Howdy folks! Anyone out there who is _happily_ using
Guitar Rig 2 on Linux? I might need to sell my freedom
and keep using Windows, because Guitar Rig 2 is so
awesome I can't live without it.
Looks like some folks have tried it on Linux and looks
like they've got it to communicate with Jack as well,
but I'd like to hear some comments from you folks on
this mailing list about this.
http://ubuntuforums.org/showthread.php?t=197536
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
Quoting Ismael Valladolid Torres <ivalladt(a)punkass.com>:
> Can it be done? I mean, chain "preamp plugin + EQ plugin + speaker
> plugin" into a single plug-in preset that can be loaded later. Is LASH
> the way to go?
You can chain the plugins. How depends on the application. In most
applications (for example ardour, jack-rack), you just add multiple plugins
and they run in top-down order.
Sampo
Greetings all,
For the impatient, download at:
http://ico.bukvic.net/Max/munger1~_1.0.0.tar.gz
(270KB, includes source, Linux-Pd-i386, Mac-Max-i386, and Win32-Max-i386
binaries, and 3 cases of beer)
OVERVIEW
========
munger1~ (March 12, 2007 1.0.0 release)
a realtime multichannel granulator
a.k.a. the swiss-army-knife of realtime granular synthesis
a flext (cross-platform PD & Max/MSP) port of
the munger~ object from the PeRColate library (0.9 beta5)
http://www.music.columbia.edu/PeRColate/
Original PeRColate library by:
Dan Trueman http://www.music.princeton.edu/~dan/
R. Luke DuBois's http://www.lukedubois.com/
Flext port and additions by:
Ivica Ico Bukvic http://ico.bukvic.net
Ji-Sun Kim hideaway(a)vt.edu
http://www.music.vt.eduhttp://www.cctad.vt.edu
Released under GPL license
(whichever is the latest version--as of this release, version 2)
For more info on the GPL license please visit:
http://www.gnu.org/copyleft/gpl.html
ACKNOWLEDGEMENTS
================
Many thanks to Dan Trueman for open-sourcing this great object!
SOURCE INSTALL
==============
If you simply intend to use prebuilt binaries, please skip to the INSTALL
section. Otherwise take a big breath and read on...
1) You need stk library which can be downloaded from:
http://ccrma.stanford.edu/software/stk/
2) You need to also install latest flext library (this is a library that
allows for creation of externals for both Max/MSP and PD using the same
source). Version 0.4.x can obtained from the following link:
http://grrrr.org/ext/flext/
Latest CVS version (0.5.1) is found in the Pure-Data CVS (this one is
recommended):
http://sourceforge.net/cvs/?group_id=55736
3) If you are using latest CVS version (0.5.1) Before compiling the source
you will need to add the following to the top of the flext/source/flstk.h
file right below the #define __FLSTK_H:
#ifdef PI
#undef PI
#endif
This step will probably become quickly obsolete once Thomas updates CVS.
Until then, this is needed to be able to compile flext against stk.
4) To compile flext, read flext instructions (it boils down to running
build.sh with appropriate parameters and then editing two simple config
files, i.e. "build pd gcc build" or "build max gcc" or "build max msvc"
etc.)
Your will need to edit buildsys/config-<platform-compiler-pdormax>.txt to
adjust paths to various folders.
Then you will need to edit config.txt file. You do not need to include
SndObj for this external but you do need stk option to be properly set. On
Windows+MSVC, STK flag at the time of this release does not work, so you
will have to use included testmunger1 MSVC project file and adjust path
settings to compile munger1~.
5) Once stk and flext are compiled, go into munger1~ folder and type:
<path to flext folder>/build.sh <platform> <compiler> <build/clean/install>
NB: on Mac <build/clean/install> is not needed. On Windows, please use MSVC
and open the testmunger1 project file in the root of the folder.
6) Once compiled, your binary will be created in a <maxorpd-platform>
subfolder (i.e. pd-linux, or max-darwin), followed by another subfolder
which reflects whether a threaded or singlethread flext was used. Inside you
will find your external.
INSTALL
=======
You can either use the prebuilt externals (found in the bin/ folder) or ones
built using the "SOURCE INSTALL" instructions above. Binaries are provided
for Intel-based Macs, Win32, and Intel-based Linux OS. The included prebuilt
binaries DO NOT REQUIRE you to install flext or stk as these are statically
linked.
1) Copy the external in your externals folder (i.e. /usr/lib/pd/extra or
C:\Program Files\Cycling '74\MaxMSP 4.6\Cycling '74\externals\, or
"Applications/MaxMSP 4.6/Cycling '74/externals)
2) Copy appropriate help file (found in the help/ folder) into the help
folder (i.e. /usr/lib/pd/doc/5.reference or C:\Program Files\Cycling
'74\MaxMSP 4.6\max-help, or "Applications/MaxMSP 4.6/max-help)
NB: Pd help file has a ".pd" extension, while Max/MSP help file has a
".help" extension.
3) Start your app (PD or Max) and create object called munger1~. Right-click
(ctrl-click on Macs) and select "help" and this should open the help file
with additional documentation.
Questions? See OVERVIEW for contact and Q&A info.
Enjoy!
FAQ
===
The following is Ico's FAQ, so it may or may not reflect other project
participants' opinions, including original author(s) of munger~, flext, etc.
Q: Why porting to flext?
A: Flext library (by Thomas Grill) is a layer which allows creation of
externals for both Max/MSP and PD without any alterations to the code
(obviously once it is adapted to use flext). While there have been a number
of Max/MSP <-> PD external ports in the past, many of them have become
outdated because such attempts required either maintaining one code full of
ugly #ifdefs, or worse--maintaining two sources. Either way, what usually
turned out to be the case is that original authors did not have the time,
interest, or simply the software/hardware to deal with the newly generated
overhead and/or test the code, while volunteers who made the original
porting efforts eventually moved on to other projects. The result was/is
outdated and/or broken externals. Flext circumvents this problem by allowing
one clean code to compile on both platforms while also supplying in many
cases cleaner (more legible) API and (as a whipped cream on top)
object-oriented environment (C++).
Q: Why bother with PD <-> Max/MSP cross-platform compatibility...
...when I use only <insert-your-favorite-application-here>?
...<insert-your-favorite-application-here> is better?
A: Choice is what makes us human (this is also what makes Arts so vibrant
and exciting). And while everyone's welcome to express their own
preferences, we also have to realize that in this case these same
preferences are also the main cause of a virtual divide which manifests
itself at everyone's detriment. Wouldn't it be nicer if we could share
externals transparently, or even better, open PD patches in Max and
vice-versa? This would help in both the cross-pollination of ideas as well
as creative efforts. This project has also taught me that creating
flext-ready externals is as easy if not easier (due to the aforesaid API's
legibility) than native objects (whether that be PD or Max/MSP). Finally, if
all else fails, such externals are bound to reach wider audience, and are
much easier to maintain if cross-platform compatibility is to be pursued.
Q: If flext is so cool, why don't we see more porting efforts?
A: Good question. The fact is that flext is much more widely known among PD
users than it is among the Max/MSP community, so this seemingly one-way road
may have contributed to the current situation. One could only hope that
projects like this may help reverse this unfortunate trend.
Q: So, is all really that peachy in the flext-land?
A: Well, our lives teach us that nothing is truly free in this world. Flext
is no exception. Its "fees," however are not tied to our checkbooks. Rather,
they manifest themselves in a slightly greater CPU overhead in signal flow
due to message translation. Thus, one could consider flext a "middle-person"
between the <app-of-your-choice> and the external. This, however, in today's
world is so negligible that during the testing phase I was unable to measure
any noticeable CPU-overhead difference.
Another consideration is that flext might not be complete (see KNOWN ISSUES
for an example). That being said, in its current state it did the trick for
a relatively complex external such as munger~ or even FFTEASE collection
which had been ported several years ago. All this leads me to believe that
it is more than ready for the day-to-day use.
Q: I already have Dan and Luke's awesome PeRColate lib. Why should I
download this one?
A: This is a cross-platform port of the latest version with several new
features. Thus, it allows for those platforms which have not had the beta6
available (Linux, Windows) to finally dig into all the goodies it brings.
Plus you also get the cool stuff such as verbose modes, discrete panning,
more thorough documentation, up to 500 grains per sample (instead of 50), up
to 24-channel output (instead of 2 or 16, depending which one you used),
etc.
KNOWN ISSUES
============
munger1~ has been tested extensively on Linux+PD, OSX+Max/MSP and
Win32+Max/MSP setups, suggesting that it should work on other setups as
well. Your mileage may vary, though.
Currently there is only one known issue in the wild which requires changes
to flext in order to be fixed. Namely, if you use munger1~ object in
conjunction with an external buffer in PD (known as an array) and if you
dubiously decide to delete that particular buffer in the middle of your
performance while munger1~ is still associated with it, this will
[unsurprisingly] crash PD. Max/MSP currently has a check implemented against
that via flext layer so Max/MSP will simply stop outputting anything until
buffer is reset. The flext author is aware of this and PD fix should appear
in the flext CVS hopefully soon. That being said, the lingering question is
why would you want to do this in the first place...
FYI, even though munger1~ allows up to 500 simultaneous grains per sample
and has been compiled with all available optimizations (SSE, Altivec is
supposedly available via flext but has not been tested), on MBP (Core Duo
1.83GHz) I was unable to get more than 160 simultaneous grains per sample
(or ~32,000 grains/second) without dropouts, even though CPUs were not
getting maxed out, so something else might be the cause of this limitation
(flext?). Win32 machine (3-year old AMD64 3000+) fared marginally better at
around 165 simultaneous grains per sample (or ~33,000 grains/second) before
its CPU was maxed out. Linux on the same AMD64 3000+ hardware fared the
best. It topped off at 47,999 grains per second at 48KHz sampling rate which
for some reason the sampling rate appears to be the upper limit (i.e. if you
run PD or Max/MSP at lower sampling rates, your upper limit will be
restricted to the sampling rate), even though the code allows for multiple
initiations of grains per cycle. This, however, is also the way original
munger~ works.
An interesting bit is that while on Linux/PD combo 48K grains are already
reached when we get 64 simultaneous grains, on Win32/Mac even 160
simultaneous grains yield only ~32-33K grains. Could this be a flext bug?
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/people/faculty/bukvic/
Hallo!
For a fried I should remove the voice (female) from a record (base -
drums - piano - voice).
Is there any software under linux with such a tool ?
I already tried inverting one channel and subtracting it from the first
one, but it's not possible with that record ...
Thanks,
LG
Georg
specimen 0.5.2-rc3 is now available. It has been a long time since 0.5.1
was released so I would like to get a lot of feedback and testing before
making 0.5.2 final. Download the tarball here:
http://zhevny.com/specimen/files/specimen-0.5.2-rc3.tar.gz
The major new features since the last release are LASH and jack-midi
support. Also of note: multiple instances can now be run at once;
set jack client name via commandline; windows are resizeable.
Change from rc2:
-Fixed configure's Build Summary output.
Changes from rc1:
-Works without jack midi, with old jack midi or with new jack midi
-Fixed --disable-lash option to configure.
-specimen windows are now resizeable and the about dialog is transient
and obedient. (Nedko Arnaudov)
-fixed pixmap loading and installation (twice).
-reworked commandline options and added usage output.
Usage: specimen [options] [bankname]
Options:
-n, --name <client_name> Specify jack client name
-h, --help Display this help message
For more information see http://zhevny.com/specimen/
Please test and report any issues here or to the specimen list:
specimen(a)zhevny.com (NB: unsubscribed messages are moderated.)
Thanks,
Eric Rz.
So I found the answer to my prayers, Rotter...
Before I downloaded it, I installed jackd ver. 0.101.1 on my ubuntu box.
So I downloaded the source, did the typical gunzip and tar -xvf then
./configure of the beast and I get this:
mlyon@kkup-audio:/rotter-0.1$ sudo ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for inline... inline
checking for sqrt in -lm... yes
checking for lrintf in -lm... yes
checking for powf in -lmx... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for JACK_CFLAGS...
checking for JACK_LIBS...
configure: error: Package requirements (jack >= 0.100.0) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively you may set the JACK_CFLAGS and JACK_LIBS environment variables
to avoid the need to call pkg-config. See the pkg-config man page for
more details.
The powf I believe is required if I was going to use mpg2, which I am
not. Going to be MP3. But the issue I am wondering about is the:
configure: error: Package requirements (jack >= 0.100.0) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
I am running jack ver 0.101.1.
Anyone know what the issue is here?
Any help would be appreciated.
Thanks,
Mike