<ralf.mardorf(a)alice-dsl.net> wrote:
> With my CPU [1] resampling seems to be still a problem. I'm using
> Qtractor, but didn't use it's time stretch feature for audio clips,
> instead I used Rubber Band as plugin to pitch down drums. This forced
> the CPU to it's knees. Another issue might be trouble because of
> transients. I like Rubber Band as an effect, so I'm fine with
> transients, but for your needs they might be a problem.
> http://www.breakfastquay.com/rubberband/technical.html
Found a new one Zita-resampler. Can't wait to try it.
http://www.kokkinizita.net/linuxaudio
So far I'm only using SRC, currently writing classes for the others.
So far so good if I don't push it with waay too many audio tracks.
To all, for your information.
I have received the following message from Mr. Nick Copeland.
It was sent privately, but since this is the continuation of
a thread on this list and the person concerned has well gone
beyond any reasonable limits of decent behaviour I feel free
to post it here.
*** Start included message ***
The last time I looked at the AMS source code I was under the impression
that the Moog VCF filters were not actually yours, they were Tossavainen
and Kellets. They were published eventually placed on musicdsp.org however
there are a couple of things here:
1. In their original publishing they did not advocate the use of
quantisation of their parameters - you implemented this as an
adaptation of their algorithm.
2. In not quoting the original authors you are plagiarism them.
In the source to AMS they are quoted however it is bit disingenious
to imply that this was 'your' MoogVCF.
In short you did not actually write the 'Moog' VCF parts and
suggesting that this is how their algorithms worked is just
attempting to justify quantisation to 1/16 is not deleterious
to quality which is definitely not attributable to the original
authors.
>From what you are saying I would like to just say you are an
arrogant selfpublicist however base on the claims in your email
you are actually a lying plagiarst.
Regards nick.
*** End included message ***
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Once upon a time, jack_diplomat was alive and well. Sadly, all
attempts to find it have failed, as the hosting site seems to be,
extinct.
Does anyone have a copy of this app on their machine that they might
consider sharing?
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
Hi,
The sequencer/arpeggiator/WYWTCI I'm working on, (eventually) will
partially generate MIDI events (primarily NOTE-ON/OFF) from a pattern. The
pattern consists of equi-distant intervals (ie 1/8th or 1/16th etc), where
each interval has the potential to play a note or not.
The note pitch and velocity is generated by something akin to window
placement. Given a grid: pitch @ X, velocity @ Y, place a box within the
grid using an algorithm to prevent overlapping other boxes* etc, but only
when the pattern says to do so.
Initially I thought I'd have this generative stuff within the JACK process
callback, but soon decided not too...
Here is how I think this will work:
1) The 'pattern processor' processes 1 quarter note at a time (I guess)...
looking ahead, processing notes which will be playing shortly, adding the
generated note data to a main event list for the sequencer (??)
2) The sequencer processes the main event list, creating the MIDI events
and adding them to a jack_ringbuffer.
3) the JACK process thread/callback reads the jack_ringbuffer and outputs
the MIDI events it finds there to the JACK MIDI port.
Now, somewhere along the line, the GUI has to provide visual feedback at
exactly (or as exactly as possible) the time any note on/off occurs.
Perhaps then:
4) the JACK process thread/callback upon sending a midi event, adds to a
2nd ring buffer which is read by the GUI thread, and displays the visual
feedback (ie a coloured box).
Also, the 'pattern processor' will need to be notified of note off events
so it can remove the box from the grid (such that new notes might replace
the old). So..
5) the Jack process thread cb upon sending a note off adds to a 3rd
ringbuffer which is read by the pattern processor to notify it of the
removal of a note/box.
Does this sound about right?
Cheers,
James.
* see also: http://jwm-art.net/art/text/xwinmidiarptoyhttp://jwm-art.net/art/text/xwinmidiarptoy.txt
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
bug fix release 0.06.0 :
fix compile issues with multi core architecture (thanks Philipp for reporting)
regards
Hermann Meyer, James Warden, Andreas Degert
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
Release 0.05.9-1 :
* add Midi learn (by Andreas Degert)
* add internal direct convolution unit with 7 filter kernel (amp models)
* add LADI level1 support
* add a new light skin
* reworked multi thread handling(by Andreas Degert)
* reduced CPU usage for Oscilloscope
To the midi learn function: a middle mouse button click on a controller pop's
up a little widget, move the midi controller you will use, the controller number
is shown in the widget. Press OK when you've done. That's it.
By the way, a right click on a controller pop up a spinbox for direct enter
the value with your keybord.
have fun
________________________________________________________________________
guitarix is licensed under the GPL.
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
For capture, guitarix uses the external application
'jack_capture' (version >= 0.9.30) written by Kjetil
S. Matheussen. If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
convolution application 'jconvolver' created by Fons Adriaensen.
If you don't have it installed, you can look here:
http://www.kokkinizita.net/linuxaudio/index.html
I(hermann) use faust to build the prototype and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
regards
Hermann Meyer, James Warden, Andreas Degert
Hi all,
I've committed to SVN an update to arpage which fixes a problem in which
arpage would not recognize a note-on event with zero-velocity as a note-off
event.
If anyone is experiencing problems with MIDI keyboards apparently not
sending note-offs, you should probably pick this up from the SVN repository.
But having said that, I'll probably have a dot release within a few days so
that I can get the fix into the PPA.
If anyone has ideas for something (simple!) they want added/fixed, let me
know and I'll try to get it into the dot release.
Thanks,
Mark Vitek
On Wed, Jan 13, 2010 at 10:53 PM, Mark Vitek <straypacket(a)gmail.com> wrote:
> Hello all,
>
> The second development release of arpage is available on sourceforge in
> source tarball and SVN formats:
>
> Tarball: http://sourceforge.net/projects/arpage/
>
> SVN: https://arpage.svn.sourceforge.net/svnroot/arpage/branches
> https://arpage.svn.sourceforge.net/svnroot/arpage/tags
>
> I'd like to thank everyone for the feedback I received on 0.1 - Please
> check this out and let me know what you think, or if you have problems
> building/running.
>
> The UI is still dead-boring GTK, but I've read back over the LAD threads
> regarding audio-oriented UI libraries and I'm thinking of investigating
> libproaudio with the next release.
>
>
> The 0.2 Development release adds:
>
> - Smaller UI - probably not Netbook friendly yet, but getting closer :)
>
> - UI should be dependent upon GTK+ 2.12 (rather than 2.16 as with the first
> release).
>
> - An additional executable named "zonage" which allows the MIDI note input
> to be split into 4 ranges.
> This is useful for routing sections of your MIDI keyboard to different
> JACK inputs - e.g. route the lower half to arpage, and the upper half to a
> "lead" sound, so you can "solo" over the arpeggiator.
>
> - The ability to have a pulse duration (time between note-on and note-off)
> be longer than the interval between pulses (time between note-on and
> subsequent note-on).
> This is useful when routing the output of one arpeggiator to the input of
> the next arpeggiator. Experiment and hear it :)
>
> - Noticeable decrease in the number of stuck notes (I haven't experienced
> ANY with this version yet).
>
>
> Basic features/requirements (same as 0.1 Alpha):
>
> - svn / tarball only for now
> - gtkmm-based, so dev packages for gtkmm and friends are needed to build
> (and obviously jack)
> - I've only built it on Ubuntu Studio (karmic) 64bit. I'm looking for
> others to let me know if it builds/runs elsewhere.
>
> - requires JACK time master to be rolling for the arpeggiators to do
> anything. Qtractor and Seq24 have worked well for me.
> - will pass midi events thru when JACK time master is not rolling.
>
> - 4 arpeggiators with transpose, interval, range, note duration selectable
> thru UI.
> - Each arp has it's own JACK midi in and out port, so you can cascade
> arpeggiators.
>
> - Preliminary support for scales and modes - all of them are not correct,
> but try major, dorian, diminished and augmented for starters :)
>
> It sounds great with each arpeggiator driving an instance of calf mono.
> Check out the ogg/mp3 clip on sourcefourge.
>
> Thanks all,
>
> Looking forward to any and all feedback.
>
>
hi...
i am working on a c++0x DSP library.
variadic templates prove to be a nice way to handle
the massive function inlining required to build efficient samplebased
processing graphs.
the idioms i am currently using for the containers require gcc-4.5
though, so this is still a bit of a show-stopper :)
its still in a pretty early state. but you can already see where its
heading.
if somebody is interested:
http://hochstrom.endofinternet.org/trac/ttsoot/wiki
--
torben Hohn
Dear Linux Audio developer, user, composer, musician, philosopher
and anyone else interested, you are invited to the...
Linux Audio Conference 2010
The conference about Open Source Software for music and audio
May 1-4 2010
Hogeschool voor de Kunsten Utrecht (HKU)
Utrecht, The Netherlands
Registration is open, and so is the call for abstracts and papers.
More information can be found on the website:
http://lac.linuxaudio.org/2010
For previous editions, look here:
http://lac.linuxaudio.org
For concerts, music and workshops a submission system and protocol will
be available soon. In the meantime, ideas and announcements can be sent by
e-mail ("lac -at- linuxaudio -dot- org ")
or written on the wiki:
http://wiki.linuxaudio.org/lac2010
We hope to see you all in Utrecht !
Kind regards on behalf of the LAC team,
Marc Groenewegen, lecturer music software design @ HKU
Hi,
I recently was testing out Seq24 >> Arpage >> Yoshimi, and it sounded
terribly out of time. This is on a fairly new Gentoo install so I
wondered if something was misconfigured. I also tried the first release
of Arpage and same result.
Then I noticed the latency of the Jack settings in use was quite high and
reset it to give a much lower latency which completely fixed the timing
problems the above seq/arp/synth setup was having.
The next test involved the Dino sequencer, but before doing so I
attempted to change the Jack settings to give a really bad latency,
170ms+. Jack could not start with such high latencies - the Alsa driver
would not load IIRC.
I reset the Jack settings for the worst latency I could get with Jack
starting, but the timing in Dino although far from perfect, was nowhere
near as bad as Arpage.
1) Is there any way to improve Jack Midi timing when the audio driver has
a high latency?
2) What is the reason the Alsa driver/Jack would not start when the
settings give a big 170ms+ latency?
BTW, I'm doing this stuff so I can program with Jack Midi.
TIA,
James.
