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
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/
Hey guys!
I was wondering about the following.
On Windows we have lots and lots of plugins and synthesizers and effect
racks. On Linux the selection is much less variable.
However, am I correct in understanding that the variety of the Windows
synths and plugins merely means that people take several core modules and
just rearrange them into different GUIs?
Am I correct in understanding that there are only several major algorithms
for things like filters, delays, reverbs and choruses?
Louigi Verona.
Hi,
I'm trying to add a threaded timer to kluppes looperdata.c
looperdata_calc_sample_stereo function so that I can add a delayed
restart to the loop process.
Can anyone tell me why the "while" statement in the following code locks
up the audio stream for the loop it is being run on? I end up with a
buzz throughout the delay period instead of a nice quiet delay period.
#include <stdlib.h>
#include <signal.h>
#include <stdio.h>
/* This flag controls termination of the main loop. */
volatile sig_atomic_t isdelay_countdown = 1;
/* The signal handler just clears the flag and re-enables itself. */
void catch_alarm (int sig){
isdelay_countdown = 0;
signal (sig, catch_alarm);
}
vol = data->vol;
if(data->playbackdelay > 0){
/* Establish a handler for SIGALRM signals. */
signal (SIGALRM, catch_alarm);
isdelay_countdown = 1;
/* Call alarm to countdown length of
playbackdelay */
alarm ((int)data->playbackdelay);
/* Check the flag once in a while to see when to
quit. */
while(isdelay_countdown){
looperdata_set_vol(data,0);
data->isplaying = 0;
}
}
/* return to start of loop */
looperdata_set_vol(data,vol);
data->isplaying = 1;
data->playindex += data->loopstart - data->loopend;
--
Patrick Shirkey
Boost Hardware Ltd
Hello,
I'm still trying to develop my boxy-sequencer idea. Basically, I've tried
out a couple of algorithms for window-manager-like box placement within a
grid and run into big problems.
Because I need help/advice/ideas, I'm posting here as it has some
relevance, and I've also posted to
http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-a…
A quick run down of what's happened so far, the two algorithms:
The first I directly based on Fluxbox's Row Smart placement algorithm.
Testing only the data structures, (and with gcc -O0) jack kicked out my
client after around 200 boxes were placed in a 128x128 grid. I then
counted how many times the algorithm looped through the entire list of
boxes and discovered (not in RT for this) that the 256th box placement
required around 14000 scans through the list of 255 previously placed
boxes (i've decided 256 boxes will be the worst-case-scenario).
The second algorithm consists of a freebox data structure which represents
a rectangular area of free unused space. It also forms a node in a doubly
linked list, as well as four directional links to other freeboxes touching
it (with a maximum of one freebox touching each side of a freebox)...
turns out rather complex to implement fully: 700+ loc for a partial
implementation of row-smart left-to-right top-to-bottom placement - theres
also col-smart, r-to-l, b-to-t and all combinations.
Through stackoverflow, I've come across spatial hashing.
I wondered if anyone here uses this technique for the display of data
(would scrollable window views use such a thing?). worth it for a 128x128
grid etc?
I'm just after any general thoughts/insights you might have as to what
might or might not work. Anything worth pursuing.
I'm afraid there's all sorts of little things to be considered so if you
do have something to suggest, please read the stackoverflow post first.
Cheers for any help, if possible,
James.
Although my provider's spam filter still blocks linux audio mails, I'm
happy to announce my novation launchpad midi driver.
It is not a driver in the common sense, but a user space usb application
which offers a midi out and in to write and receive launchpad midi messages.
On my distribution(gentoo) I needed to add myself to the usb group to
run this application.
Download it from: http://krampenschiesser.de/launchpadd-0.1.tar.bz2
Dependencies:
I know the dependencies are quite fat(boost) but this driver is part of
my sequencer application, and I just want to give launchpad owners the
possibility to use their pad.
boost >= 1.41 (need threads, signals2, foreach)
libusb-1.0
alsa
pthreads
To build the whole stuff you need cmake(>=2.6).
Installation:
$ tar -xjf launchpadd-0.1.tar.bz2
$ cmake
$ make
$ sudo make install
$ launchpadmidid
To uninstall use :
$ xargs rm < install_manifest.txt
I would be very happy to get some feedback from the users and developers.
Coming from the Java world this is my first(finished) project in c++ and c.
And I didn't know anything about USB before...
So if there is a developer who has got a good knowledge of c/c++ or usb
interrupt transfers it would be great if he could have a look at the
code, especially the method handleWriteTransfer in LaunchpadImpl(.cpp)
is a point where I'm not that sure about the interrupt handling(although
it works as it is right now).
If there's anyone using this application on a kernel <=2.6.27 please
inform me(as the polling changed with this version).
