Hi,
I've uploaded the tkeca website.
Take a look of this:
http://tkeca.sourceforge.net
I know, I know ... I'm not a graphic designer.
Regards,
Luis Pablo Gasparotto
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
Hi all,
No response to the beta testing request, so I'll have to subject you all
to a likely hairy release :) Arbitrary channels are the biggest thing.
Also, previous save files will no longer work as the save files use XML
now. Sorry, but it's better to change it now instead of later as
changing the xml format will create less of a disturbance.
* can now have arbitrary channel numbers. you can use any plugin that has
equal numbers of input and output channels where they divide exactly into
the number of rack channels. eg, you could have a 4 channel rack with 2
stereo plugins in one slot and 4 mono plugins in another. obviously, you
can also have mono racks now. use the -c command line option to specify
the number of channels on startup.
* now, when you lock a group of controls, only one widget will be shown.
click on a control while holding down the CTRL key to make it the one that
remains visible.
* the PID is now used in the jack client name by default. you can change it
to the previous behaviour (of using just "jack_rack") with the -n option.
* save files now use an XML format (which is incompatible with the previous
format, sorry)
* port connecting works now, -i to connect inputs, -o to connect outputs
* quite a bit of code factoring and cleanups and stuff
http://pkl.net/~node/jack-rack.html
Bob
--
If you're happy and you know it, bomb iraq
Hi all, a small question regarding getting this thing to work. I'd
appreciate any help I can get.
I am running MDK 9.0 and am trying to get Midisport 2x2 to hotplug. The
problem is that if I use the ezusbmidi script (obviously coupled with
the right firmware and hotplug stuff) the /var/log/messages definitely
notes its successful recognition of the device and announces the last
line echo that the firmware has been installed onto the device
/proc/bus/usb/002/021 (or whatever number it gets assigned), yet the
midisport remains dead.
I understand that the ezusbmidi script uses fxload to upload the
firmware, but according to the syntax of the ezusbmidi script it sends
the command in the following format:
Fxload -I /path/to/firmware
But this is not sufficient when you try just fxload by itself, it
complains that it is missing the destination device (-D flag).
So subsequently I am guessing that this is the stepping stone but then
how is everyone else getting this thing to work.
OTOH, when I try ezusb2131 it works flawlessly (manually) but there is
no automation script for it, so I know that everything loads properly,
it is just that my fxload for some reason is not working properly.
I tested my midi after using ezusb2131 and it does work (/dev/midi1).
Now, I hacked the script for the ezusbmidi and it does hotplug, but it
is an ugly hack and I am wondering what is wrong with this picture?
Any help is greatly appreciated!
Sincerely,
Ivica Ico Bukvic
Forgot to mention that I blacklisted usb-midi and audio drivers in the
/etc/hotplug/blacklist. The computer tried also to load snd-usb-audio
(why?), so I blacklisted that one as well.
Btw, using Alsa 9.0.rc5.
Finally, even though the /var/log/messages mentions creating two pairs
I/O ports (since it is Midisport 2x2) I only have one /dev/midi1 device
hooked up I guess to the first 16 channels. Where are the other 16?
Any help is appreciated!
Ico
hello * !
after what looks like a server upgrade (if you can call 2.0.40 an
upgrade), the LAD homepage is broken. (yet again.) i hope root@localhost
will be able to fix it, and maybe he will set the server admin mail
address properly while he's at it...
sorry for any inconvenience.
the archives can be reached directly at http://eca.cx/lad,
http://eca.cx/lau, and http://eca.cx.laa .
the mailman web interface is available at
http://music.columbia.edu/mailman/listinfo .
best,
jörn
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
David Seymour
Benchmark Media Systems
800-262-4675
www.benchmarkmedia.com
-----Original Message-----
From: David Olofson [mailto:david@olofson.net]
Sent: Monday, February 03, 2003 10:26 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Re: linux-audio-dev digest, Vol 1 #312 -
8 msgs
On Monday 03 February 2003 15.36, Ben Loftis wrote:
> >> > * The "save state chunk" call seems cool, but what's
> >> > the point, really?
> >>
> >> This could be useful for state storing in hosts, but how many
> >> would use it? I'd certainly be reluctant to implemnt it.
> >
> >Right... I'm not even sure what state we're talking about here,
> > but I *assume* it's basically all you need to continue playing
> > from where you saved the state. Freezing reverb tails and stuff?
> > Sounds fun but pretty useless... Might help some very special
> > apps - but then, will it be sufficient?
>
> If you want to restart playback at an arbitrary point and be
> sample-accurate, you must have this, right?
Nope. Sample accuracy has nothing to do with it. You'd just start
playing and make sure there are events to set the transport at the
right position before the first sample frame. (Or if you have the
plugins running all the time, you just start the sequencer, period.)
> I think it's a good
> idea (I suggested it myself a while back). The host can cache
> these at regular intervals (and at the user's locate points) so you
> can start playback and the host only has to preroll from the most
> recent state chunk. Implementation is easy if you design for it...
> just stream all your internal variables into a buffer.
So, we're basically talking about a brute-force solution to the
classic "make MIDI behave as recorded audio" problem?
It could work in theory, but what about the bandwidth required for
some plugins to do this correctly? You'll have to drop delay buffers
and the like, and then it's not a complete solution anyway. Could
work pretty well for synths though, and that's probably the
interesting part.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
>
>> > * The "save state chunk" call seems cool, but what's
>> > the point, really?
>>
>> This could be useful for state storing in hosts, but how many would
>> use it? I'd certainly be reluctant to implemnt it.
>
>Right... I'm not even sure what state we're talking about here, but I
>*assume* it's basically all you need to continue playing from where
>you saved the state. Freezing reverb tails and stuff? Sounds fun but
>pretty useless... Might help some very special apps - but then, will
>it be sufficient?
If you want to restart playback at an arbitrary point and be sample-accurate, you must have this, right? I think it's a good idea (I suggested it myself a while back). The host can cache these at regular intervals (and at the user's locate points) so you can start playback and the host only has to preroll from the most recent state chunk. Implementation is easy if you design for it... just stream all your internal variables into a buffer.
-Ben
Hi all,
I'm about to release a new version of jack rack, so rather than let it
go and then release a load of fixed versions over the next week, I
thought I'd try a beta test type thing seeing as the code is now in
cvs. So, if anyone would like to test the new version, you can get the
cvs info from http://sourceforge.net/cvs/?group_id=71639 . Module name
is "jack-rack". Reports can go to myself or, preferably, the mailing
list, jack-rack-devel(a)lists.sourceforge.net.
Cheers,
Bob
--
If you're happy and you know it, bomb iraq
> Subject: RE: [linux-audio-dev] Fwd: Creative's IP concerns
> From: Pieter (pieter.palmers_AT_student.kuleuven.ac.be)
> Date: Thu Jan 24 2002 - 17:43:23 EET
[...]
> Pieter
> PS: I'm not really certain of this, but I think
> The help for developping the SAM9407 driver came from Terratec.
> They seem to be much more open to Linux users than Guillemot.
> But I think the main problem is Dream,
> because everyone I contacted about info started nagging about
> 'having a NDA'... when are HW manufacturers going to learn...
I am the author of the sam9407 device driver for Linux.
I do not agree with your observation:
Terratec never replied to any of my inquiries directly, and only after
one year of efforts they started to offer an NDA, which I did not sign.
Guillemot was compared to that relatively open.
Dream was along the lines of Guillemot, after some initial effort,
I had a contact person I could turn to.
Hoontech ranked best in that regard.
Terratec ignored my efforts until the end.
Other people on the sam9407 development list that went to meet Terratec
people on trade shows were simply pointed to the "Linux Community"
that would in their opinion already work on a driver.
Check out the README file in the package, that has an event log
and some ranting about that http://sam9407.sourceforge.net
Best Regards,
Gerd Rausch