After more than 10 years of service my first ever Linux system
died yesterday. The original configuration was P4, 0.5G memory,
two IDE HD of 60G each, and it pretty much stayed like that.
Two years ago the power supply blew up and was replaced by an
external one (too big to go inside). Last year the first HD
failed, and yesterday evening the second.
This was the system on which I developed almost everything I
ever released, so it carries lots of memories... Maybe one
of the reasons it decided to go to the eternal processing
fields was that it couldn't really cope with A3. I've mixed
20+ tracks using A2 on that system, but 350MB resident memory
for an empty session was just too much...
The new zita1 will probably be a Fujitsu P510, one of the
reasons being that this is one of the few still having at
least one PCI slot, so I can still use my sound cards. Any
suggestions for alternatives are welcome !
More CPU and memory will in the end make me less frugal, but
I'll resist the tendency :-)
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Gordon JC Pearce wrote:
> On Sat, Aug 31, 2013 at 07:04:31PM +0200, Clemens Ladisch wrote:
>>> not to send that too soon otherwise the CZ will misbehave in various
>>> interesting ways. Once all the patch data is send - with breaks for
>>> acks in between - the final 0xf7 is sent to terminate the sysex dump.
>>
>> So the messages used by the CZ1000 in this protocol are not actually
>> MIDI messages.
>
> In what way are they not MIDI messages?
All the messages in the CZ1000 protocol (header, acks, final F7)
together make up just a single MIDI message; the individual messages,
taken separately, are not valid MIDI messages.
>>> According to the USB MIDI spec there is an event packet to send just
>>> single bytes.
>>
>> There are devices that do not support this single-byte packet.
>
> That would be most devices.
>
>>> This isn't implemented in the kernel,
>>
>> It's used for real-time messages.
>
> No, that's CIN 0x5 which only passes a single byte if its upper bit is set.
CIN 0x5 is used only for system common messages, not for system real-
time messages.
>>> With a bit of testing, I've determined that at least the USB
>>> interfaces I have at hand do not support sysex. They will pass some
>>> interestingly "interpreted" version of sysex, which is of course
>>> corrupted and unreadable by the device.
>>
>> In what way corrupted?
>
> It doesn't send complete messages.
The USB MIDI spec does not work on the raw byte level (except when
using CIN 0xf) but on the level of complete MIDI messages. (Running
status isn't used either.)
> This is an inherent flaw in the USB MIDI spec.
Apparently Roland, who wrote the spec, did not think that anybody would
do anything particularly weird.
Regards,
Clemens
Gordon JC Pearce wrote:
> On Sat, Aug 31, 2013 at 11:34:33AM +0200, Clemens Ladisch wrote:
>> Gordon JC Pearce wrote:
>>> The only exception is if I send something not a multiple of three
>>> bytes but terminate the transfer with 0xf7, it will send
>>> everything including the 0xf7 - but this kills the sysex transfer.
>>
>> _Every_ SysEx message must be terminated with F7.
>
> The CZ1000 expects seven bytes to start the sysex transfer, at which
> point it will reply with a message and wait for an acknowledge. The
> the PC should start to send the patch data, but it's quite important
> not to send that too soon otherwise the CZ will misbehave in various
> interesting ways. Once all the patch data is send - with breaks for
> acks in between - the final 0xf7 is sent to terminate the sysex dump.
So the messages used by the CZ1000 in this protocol are not actually
MIDI messages.
>>> Is it really impossible to just send raw bytes over a USB MIDI cable?
>>
>> It is possible to send MIDI messages over a USB MIDI cable.
>
> According to the USB MIDI spec there is an event packet to send just
> single bytes.
There are devices that do not support this single-byte packet.
> This isn't implemented in the kernel,
It's used for real-time messages.
> it would be incredibly handy for sysex transfers, debugging and the
> like.
>
> Perhaps the answer is just to ditch alsa and poke the USB device with
> libusb?
Or change the driver to always use single-byte packets (modify the first
"if" in snd_usbmidi_transmit_byte).
> With a bit of testing, I've determined that at least the USB
> interfaces I have at hand do not support sysex. They will pass some
> interestingly "interpreted" version of sysex, which is of course
> corrupted and unreadable by the device.
In what way corrupted?
Regards,
Clemens
Hi folks,
I'm having some really odd behaviour trying to send sysex to a synth where I can only send (using snd_rawmidi_write) in three-byte blocks. The only exception is if I send something not a multiple of three bytes but terminate the transfer with 0xf7, it will send everything including the 0xf7 - but this kills the sysex transfer.
The synth I'm trying to send MIDI to - a Casio CZ1000 - expects seven bytes of data to start a patch dump, at which point it will send a handshake back to the computer. Now if I pad the output with zeros the synth *will* handshake, but then not respond to the handshake acknowledge presumably because of the extraneous zeros.
I can't figure out what I'm doing wrong with this. Example code here:
http://dpaste.com/1361268/
This is tested with the MIDI out of my Emu 1x1 cable plugged into the MIDI in of a sound module and MIDI in on the interface plugged into the MIDI through on the module - so there is no "processing" of the MIDI messages.
Is it really impossible to just send raw bytes over a USB MIDI cable?
--
Gordonjcp MM0YEQ
http://www.kasploosh.com/projects/CZ/how_to/amidi-cz101-receive.html
:D
I missed this, since I googeld for the list ponly, so using amidi it's
possible to write a synth editor by shell script, at least sending some
commands is possible without having the knowledge how to program in a
Linux common high language such as C.
On Sat, 2013-08-31 at 07:15 +0100, Gordon JC Pearce wrote:
> On Sat, Aug 31, 2013 at 04:56:24AM +0200, Ralf Mardorf wrote:
> > http://www.kasploosh.com/projects/CZ/how_to/amidi-cz101-receive.html
> I have a proper copy of the Casio MIDI spec here. That's not the
> problem.
>
> The problem is that you can't send sysex in anything other than
> multiples of three bytes, and you need to send seven bytes and then
> wait for a response from the CZ1000. The seventh byte is never sent.
>
> It doesn't look like it's possible to do it with USB devices in Linux
> at least, because of the way that USB MIDI devices are handled -
> unless I'm missing something.
Then your MIDI implementation list is different to the one I found in
the Internet, since a dump request by this list needs different values
than those you used.
You send 44 00 00 for Casio, that's correct compared to the list from
the Internet, then you sent 70 for MIDI channel 1, that's also ok
compared with this list, but after that you sent 19, weil the Internet
claims it should be 10 to request a dump.
Than you sent 60, regarding to the Internet list its correct to request
the patch from current sound area.
You add two times 00, but the list in the Internet says that the ok
string 70 31 is needed.
On Fri, 2013-08-30 at 21:31 -0700, Devin Anderson wrote:
> You can also use `midisnoop` for this purpose:
>
> http://midisnoop.googlecode.com/
Thank you :).
Regards,
Ralf
Hello all,
REV-plugins-0.6.1 is no available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
>From the README:
--------------------------------------------
Version 0.6.1 -- 28/8/2013
--------------------------------------------
* Plugin file renamed to zita-reverbs.so.
Any older versions in /usr/lib/ladspa must be
deleted to avoid conflicts.
* Cleanup of the 10 year old original code.
* Added
# 3701 zita-reverb
# 3702 zita-reverb-amb
These are LADSPA versions of zita-rev1 in resp. stereo
and first order Ambisonic mode.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
On Fri, Aug 23, 2013 at 12:48:22PM +0100, Chris Goddard wrote:
> Hi Adrian
Hi!
Let me CC Robin and LAD on this one.
> Hope you don't mind me contacting you directly, but I have a
> question regarding the RME TCO option and how it is supposed to
> work. I saw your name on some ALSA commits relating to the TCO
> recently and thought you would at least be the right person to start
> by asking.
>
> The TCO can read ltc, but once it has done that how does it
> communicate that time information tothe user space ? If I was, say,
> running Ardour and wanted it to chase this ltc what would Ardour
> need to do to make use of it ?
To be honest: I don't know, I've only fixed the kernel side of it. ;)
There are 1.5 ways to read the TCO's LTC output from userspace:
1. Via ioctl. Needs currently unreleased alsa-lib containing my
commit 4b169b05b48f4ea0196879b62b8c3fa5b050e806 and newest driver,
Takashi's sound-2.6 is fine.
Then, use SNDRV_HDSPM_IOCTL_GET_LTC. To the best of my knowledge,
that's the proper way to read the LTC and it's what I've fixed.
2. If the TCO is present, we create a MIDI output port sending the
MTC. At least I think it's MTC. Since the data is directly
generated by the TCO, the driver has no influence on it. No idea
if it helps in your case if you set this port as the MTC input
port in Ardour.
So it looks like for proper LTC support, we either need some converter
(maybe there already is one?) or ardour needs to be augmented. I have
absolutely no idea what the preferred approach is, but I'm sure Robin or
Paul do.
Maybe it's easiest to add another input path to one of Robin's LTC libs
that just runs the appropriate ioctl and parses the output. Since the
LTC is already decoded by the TCO, it should be pretty straight-forward.
Oh, and last not least: I don't own a TCO, so I cannot really test
anything. Fortunately, the ioctl is purely software, so a mockup should
do the trick.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
Hey All,
I've written up a blog post on allocating (audio) buffers in real-time.
The trigger was designing the record functionality for Luppp.
http://openavproductions.com/realtime-buffer-allocation
Hope its of interest to some, -Harry
CAPS Audio Plugin Suite 0.9.12
http://quitte.de/dsp/caps.html
New in this release:
Eq4p, a four-way parametric equaliser
http://quitte.de/dsp/caps.html#Eq4p
(Unlike Fons', this one uses parallel processing but lacks control
smoothening other than that provided by a continuous IIR filter
history.)
Elsewhere, a few stupid bugs have been fixed (one of them keeping
PhaserII from reaching strong effect levels), the documentation has
undergone a major revision, many plugins have been polished, some
renamed, and lots of unnecessary ones have been removed.
http://quitte.de/dsp/caps.html#Download
Enjoy!
