Hi everybody,
Fallowing up the long discussion i'm trying to sort of give the
information you all seem to be missing.
there was a meantion of this, but not too many of you have paid any
attention:
here you can find an article about the current status of the protocol mess:
http://prosoundnewseurope.com/pdf/PSNLive/PSNLive_2009.pdf (page 28)
obviously eas50 is good to go, but Ethernet AVB is right thing really.
the only thing that it's still work in progress, but many of the
proprietary vendors, which already have their own networking solution
(like Harman with HiQ-net, the one i can name of top of my head)
are involved in AVB stadard deveelopment.
The idea of AVB is to bypass the IP layer, which is right thing really.
you don't need to assign IPs to your audio nodes, really!
in avb you'd just have to select channels that nodes whant to listen to.
there is a fair bit of documentation on the ietf.org AVB group's page.
but XMOS is looking to be the best point of refference:
http://www.xmos.com/news/15-jun-2009/xmos-simplifies-ethernet-avb-implement…
is think we should forget everything else and crack on with the XS1 AVB
implementation!
their XS1 chips seem to be really great,
their are basically every innovative and open-source minded.
the official toolchain is LLVM-GCC based.
you can use C, C++ or their own XC.
XC is basically C with some stuff omited (like goto and floats)
and XMOS IO stuff added, don't just say WTF, look at it first!
you should also watch the videos here:
http://www.xmoslinkers.org/conference-online-wf
especialy the two about the "XMOS Architecture" and the AVB
presentation.
some dev-kits are quite expencive, but that's due to low-volume really
;)
there is alos a nice USB Audio kit!
plus there is alittle board that is cheap and has two RJ45's on it
already :)
I'm myself studying the XC book at the moment. And geting familiar with
the tool set :)~~
looks very exciting, cause these are the invovative chips!
ok, may be an FPU is really missing on XCore, but how many DSPs have
it anyway? well quite a few, but there was no FPU on dsps for ages! :))
also XC or C/C++ are so much more obvious then the bloody "menthal american military engeneers non-sense" called HDL-whatever!
Cheers Everyone,
Hope you will appreciate my excitment :)~ (l0l)
--
ilya .d
Hiho,
I managed to get SuperCollider and JACK running on my IGEP [1], on the pre-
configured Ubuntu on the SD, but of course the audio is still bumpy.
So... I'm looking for a RT kernel for this little machine... Anyone have any
pointers?
I did find this one: http://beagleboard.org/project/omap-rt-patch/
but the project doesn't show much recent activity.
and... I also noticed that JACK didn't want to run with alsa as backend; oss
as backend works though (but gives the bumpy sound).
Anyone willing to share their experiences doing linux audio on ARM processors?
sincerely,
Marije
[1] http://www.igep-platform.com/
Hello guys!
I would like to ask any of the developers who might be interested to help a
musician out!
Original Kluppe developer seems very busy these days. And his programm lacks
two things I really need for my musical work.
I am ready to pay for the work. All the details below.
*1. Feature 1 - random play.*
When on Windows, I wrote a simple programm for myself, called Tape Loops. It
could play sounds either once or in a loop. The special function which I
added to it was "random play". What it did was allow you to define a period
of time in seconds. And the programm would trigger the sound randomly
somewhere within this period. So, if the period is 20 seconds, the programm
would play the sound either in 5 seconds, or in 10 or in 7 or in 20. When
the sounds stops playing, the timer is reset and the program once more
chooses a random moment to trigger the sound within the given period. By
changing the period the musician can make the sound get triggered more often
or less often.
The demo of how this program works can be viewed here:
http://www.louigiverona.ru/?page=projects&s=software&t=tapeloops&a=tapeloop…
It is a great feature - it helps a lot an ambient composer like myself and
is greatly useful for installations.
On Linux I have tried some programming, but even setting up JACK is very
difficult for me, I am absolutely not a strong desktop programmer. So
writing something like that from scratch on Linux is not realistic for me. I
tried Kluppe, which is the closest thing, it is a great piece of software,
but I studied the code for several days, tried some things, but apart from
changing the colors, I do not seem to be able to do anything meaningful.
So I would like to ask someone to do this job for me. To add a timer to a
kluppe looper and to allow this "random play" mode, where the musician can
put a looper into random play mode and define the period.
*2. Feature 2 - basic midi control.*
Looking through Kluppe code, I saw that a lot of midi is already done, but
it is not "attached" to the controls. I might be wrong and there may be more
work than it seems, but anyway. I would want to be able to assign midi
control to triggering loops, volume and panning - at least that. Otherwise,
Kluppe is very difficult to use in a live performance.
However, instead of proposing to allow to create separate controls for each
looper like they have in SooperLooper, I would advice (and actually, ask for
this feature to be implemented in such a manner) to instead go for the
Selected looper scheme. So that one would not need a dozen of knobs to
control things. There should be an ability to have one "Selected" looper.
Similar to what Dj Traktor Studio has. So you are binding midi not to a
definite looper, but to the Selected looper, and thus you would require only
two knobs (vol, pan) and three buttons (play/stop, Prev looper, Next
looper).
*3. Payment.*
I understand that all of the above might be not as simple as it seems to me
now. I would be willing to pay, as much as I can. I am able to pay through
PayPal. I do not know how much money is a normal pay for such work, but I
think something can be arranged. If I am not able to pay up instantly, I am
willing to pay for several months in a row to cover the necessary expenses.
I will also ask around on forums if someone will join me and also donate
some money - while my random play function is probably too specific and is
only something for me, midi control in Kluppe is something I believe many
people would want.
Thank you for your attention and I hope someone gets interested in the
request!
Louigi Verona.
http://www.louigiverona.ru/
On 5/29/10, akjmicro(a)gmail.com <akjmicro(a)gmail.com> wrote:
> Hey all,
>
> Yes, grepping for the port type which appears underneath with a 'jack_lsp
> -t' will be more consistent and dependable. Or, using a python-jack lib
> function and not depending on any system shell calls. The problem then
> becomes, is the jack lib for python well documented? If so, I think that's
> the real future of jackctl.py
>
> PS Qjackctl may be lightweight, but installing the entire QT toolkit just to
> use it is not!
>
> AKJ
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Robin Gareus <robin(a)gareus.org>
> Date: Sat, 29 May 2010 14:00:52
> To: Julien Claassen<julien(a)c-lab.de>
> Cc: Aaron Krister Johnson<aaron(a)akjmusic.com>;
> <linux-audio-user(a)lists.linuxaudio.org>;
> <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: Re: [LAD] [LAU] like "qjackctl", but trimmed of all fat
>
> Hi Julien, Hey Aaron,
>
> read 'jack_lsp --help'.
>
> '-t' does not take any arguments; it just makes jack_lsp print the type.
> the filter-string only acts on the port-name (BTW, not only the
> beginning of the port-name; but it's case-sensitive: strstr() )
>
> Anyway I can reproduce the problem, some jack-midi ports show up in the
> audio-tab of jackctl20100528b.py.
>
> jackctl20100528b checks for lowercase 'midi' in the port-name instead of
> looking up the port-type. So a2jmidi for example with an upper-case M
> "Midi.." ends up in the audio-panel.
>
> Your suggestion to parse the output of 'jack_lsp -t -c' is spot on.
> the (currently 2) possible return values are (indented by tab):
>
> #define JACK_DEFAULT_AUDIO_TYPE "32 bit float mono audio"
> #define JACK_DEFAULT_MIDI_TYPE "8 bit raw midi"
>
> ..or as you suggest using the python-module for JACK may also simplify
> things and make jackctl easier to maintain.
>
> Cheers!
> robin
>
> PS. Oh, and which of qjackctl's features makes it 'fat'? it's not
> bloated in any way. I'd rather put it the other way 'round and say that
> jackctl is 'slim'. Sorry could not resist.
>
>
> On 05/29/2010 12:23 PM, Julien Claassen wrote:
>> Hello Aaron and Jack-Team!
>> There seems to be a bug in my jack_lsp. I just started a2jmidid and
>> j2amidi_bridge. when I do a jack_lsp I get all the ports.
>> When I do: jack_lsp -t midi I only get one port from jack_midi_clock,
>> but none of the other ones.
>> When I type: jack_lsp -t, I can't see a difference between the
>> jack_midi_clock port and the others:
>> jack_lsp -t
>> [...]
>> a2j:Virtual Raw MIDI 0-0 [16] (capture): VirMIDI 0-0
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-0 [16] (playback): VirMIDI 0-0
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-1 [17] (capture): VirMIDI 0-1
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-1 [17] (playback): VirMIDI 0-1
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-2 [18] (capture): VirMIDI 0-2
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-2 [18] (playback): VirMIDI 0-2
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-3 [19] (capture): VirMIDI 0-3
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-3 [19] (playback): VirMIDI 0-3
>> 8 bit raw midi
>> a2j:M Audio Delta 1010LT [20] (capture): M Audio Delta 1010LT MIDI
>> 8 bit raw midi
>> a2j:M Audio Delta 1010LT [20] (playback): M Audio Delta 1010LT MIDI
>> 8 bit raw midi
>> j2a_bridge:playback
>> 8 bit raw midi
>> a2j:j2a_bridge [129] (capture): capture
>> 8 bit raw midi
>> Jack MIDI Clock:midi_out
>> 8 bit raw midi
>>
>> Or is the argument "midi" only seen as the start of a port_name?
>> If so, Aaron, you must rewrite this part of jackctl (I guess you do
>> what I described, because I get exactly your output). You should rewrite
>> it using:
>> jack_lsp -t
>> And then parse the type info underneath each name. I think a simple
>> grabbing for "audio" or "midi" will do. But I guess, that in the long
>> run, using the python module for jack, will be more efficient and easy
>> to use.
>> Kindly yours
>> Julien
>>
>
--
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org
Unfortunately, due to a problem with the server the nekosynth subversion
server was on, I suspect I may have lost all the source to nekobee,
nekostring et al. I don't even have a recent copy checked out of svn.
The problem has come about because the hosting company stopped invoicing
me for the hosting, and bouncing any mail sent to them. It may also be
that I need to email them in Finnish, but I don't speak the language. I
don't know. The server went down some time ago, but came back up
without SSH or svn access, so I wasn't able to pull off any backups.
If there's anyone fluent in Finnish who fancies having a go at getting
in touch with Seclan to discuss the problem, please contact me off-list.
Gordon MM0YEQ
Hi,
The MiniComputer softsynth has problems building on many distros when
fltk-1.x is installed alongside fltk2, and/or the #include directories
don't match where MiniComputer expects them to be and so the build fails
at the configuration stage.
In an effort to fix this quite long standing problem, I've adapted the
SConstruct to use fltk-config and pkg-config to solve these problems.
If you have problems building MiniComputer replace the SConstruct that
comes with MiniComputer with the following file (obviously rename it to
SConstruct first):
http://jwm-art.net/art/text/MiniComputer_SConstruct
It works for me on Gentoo (using accept keyword ~amd64).
I posted here because:
1) I saw similar questions without answers on the list in the past.
2) I've spent several hours getting this to work so people might benefit
from it.
3) I'm a python/scons newbie and hope that those of you with better
knowledge can check it for problems (I've only got this to work by using
Google, trial, and error).
Cheers,
James.
Hi all,
I just finished up my port of Autotalent (A real-time pitch manipulation
program by Tom Baran) to an LV2 plugin (Okay, It's not finished, but all the
important features are there.)
It should work basically the same as Autotalent except:
- It is an LV2 plugin instead of an LADSPA plugin
- It provides MIDI output of the pitch
- It accepts MIDI input
- It separates the pull to semitone and snap to scale functionality
- It uses FFTW for the DFT routines, greatly improving performance.
- Minor performance tweaks (substituting memcpy for loops, etc)
- It is greatly refactored (broken into methods and structures, variables
renamed)
- Does not include smooth pitch jumping or LFO functionality in the first
release (will add later)
- The formant corrector causes artifacts not present in the original (I'm
not sure how to fix, as it's the only part of the original I don't
understand)
I think especially significant is the midi input and output. This would
allow you to do the following:
- Record an audio track in your favorite DAW while running it through the
plugin, and outputting the MIDI to another track
- Correct the midi however you want (keep it monophonic)
- Feed the corrected MIDI track back into the plugin with the recorded
audio, and listen as it corrects the pitch to match the MIDI you gave!
There are also other options, such as controlling an MIDI synth with your
voice, or getting a vocoder-like effect by controlling your voice with a
MIDI keyboard.
You can check out the project page for more information
here<http://code.google.com/p/autotalentlv2/> or
if you want a direct source download, see
here<http://autotalentlv2.googlecode.com/files/autotalent_source.tar.gz>
.
Any feedback on the source code or plugin would be welcome.
Jeremy Salwen
Greetings,
Every now and then I decide to update a page on the original Linux
soundapps site. Recently I cleaned up this page for audio/MIDI plugins :
http://linux-sound.org/plugins.html
Please advise if I've left out anything or if any information there is
wrong. I've covered plugins in LADSPA, DSSI, MESS, LV2, and VST formats,
hopefully I got all the major projects, and I'd like to know if I've
missed anything. TIA!
Best,
dp
Hello all,
This week I had to perform measurements on a audio
interface, and this resulted in some quite interesting
results. Before revealing what happened, I'll let you
have a look at some of the data and come up with your
own conclusions, see
<http://www.kokkinizita.net/linuxaudio/quiz.html>
(Free beer at the next LAC for the best analysis)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !