Hello all,
zita-ajbridge-0.4.0 is now available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
>From the README:
* The 'JackPortIsTerminal' and 'JackPortIsPhysical'
flags are set on the Jack ports.
* The correct latency value is set on the Jack ports.
This is the latency resulting from buffering and
resampling. It does not include any additional
latency due to processing by the sound card, e.g.
from anti-alias filters. This can be added using
the -I (for a2j) and -O (for j2a) options, in the
same way as for Jack's ALSA backend.
The README also explains how to test this.
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)
Hi all,
I just joined the developers list as I've been looking into adding
Jack midi support to one of my favourite sequencers (harmonySEQ) and
need some advice related to threading and shared data. I know these
issues have come up before, specifically I found two related threads
[1][2], but I am still confused as to what would be the best approach.
(I am also new to thread programming in general.)
As this is a sequencer the main data structure is a list of patterns
where each pattern contains a list of notes. Patterns can be
manipulated while being played back. Both the GUI thread and Jack
thread should be able to modify the patterns, e.g. a midi event might
toggle a pattern on/off, the GUI can insert a note into a pattern, or
add or remove a pattern.
I've considered different approaches (separate data for each thread,
various versions of shared data), but I believe all of them make at
least two assumptions: That reading and writing byte-sized data (e.g.
a bool flag) and that updating pointers is atomic. I got a bit
confused reading this thread [2]. Are these assumptions correct?
To be more specific, one of the schemes I came up with followed the
idea of using only one shared data structure which has to be in a
consistent state at all points in time. To ensure this I would have to
be very careful as to how I update the data structure. For example, if
the GUI added or removed a note from a pattern (which might involve a
memory reallocation) it would do so by performing theses changes on a
copy of the current pattern and then replace the original pattern by
updating the pointer to this new version of the pattern. Simple
updates (e.g. turning a pattern on / off) would be performed directly
on the pattern as I consider them atomic. To keep references to
patterns throughout the code I would use some global registry, as I
cannot use pointers for they "expire" (might point to an old version
of the pattern).
Does that make sense? Are there some obvious flaws with that scheme
that I oversaw, are there better ways to go about it? I am really
quite new to this kind of programming issues, I would appreciate any
pointers and advice!
Thanks,
Burkhard
[1] http://linux-audio.4202.n7.nabble.com/Best-practice-for-sharing-complex-dat…
[2] http://linux-audio.4202.n7.nabble.com/Atomic-Operations-td58961.html
Hey everybody,
OpenAV is releasing Sorcer 1.1! Upgraded features such as a compressor and
output level provide better feedback in an all new NTK based UI! Existing
presets are remain unchanged: the compressor is off by default.
Packagers will be happy to know that Sorcer now uses Make, so packaging
should be easier.
Details available on http://openavproductions.com/sorcer
Cheers, -Harry
Hi,
I'm writing a CLI editor for the Matrix-1000. Regarding to the owner's
manual some parameters have 6 bit values, so I gave them a range from 0
to 63, for the 7 bit value I definite a range from 0 to 127. Many values
are described as "7 (Signed)". I consider those values should get a
range from -64 to 0 to +63, IOW I understand it as a two's complement,
but the editor of my Atari ST's Cubase 3.1 doesn't give them a value
from -64 to 0 to +63, instead the GUI's value range is from 0 to 127. I
suspect that the Cubase editor is mistaken, resp. the editor was build
by a "kit" and I suspect there's a limitation, it doesn't know signed
values.
My guess is, that it would be correct to assign a value range from -64
to 0 to +63. Is this correct? Or am I mistaken and the value range given
by Cubase is correct?
Regards,
Ralf
On Thu, 2013-09-12 at 14:22 +0200, Alexandre Ratchov wrote:
> On Mon, Sep 09, 2013 at 04:45:53PM +0200, Ralf Mardorf wrote:
> > Hi,
> >
> > I'm writing a CLI editor for the Matrix-1000. Regarding to the owner's
> > manual some parameters have 6 bit values, so I gave them a range from 0
> > to 63, for the 7 bit value I definite a range from 0 to 127. Many values
> > are described as "7 (Signed)". I consider those values should get a
> > range from -64 to 0 to +63, IOW I understand it as a two's complement,
> > but the editor of my Atari ST's Cubase 3.1 doesn't give them a value
> > from -64 to 0 to +63, instead the GUI's value range is from 0 to 127.
>
> I don't have a matrix-1000, but there's plenty of midi gears that
> use biased 7-bit integers instead of signed two complement. I mean:
>
> 0 -> min value
> 64 -> neutral value
> 127 -> maximum value
>
> example, a value in the [-0.5:0.5] range would be represented
> with the 7-bit number in 1/128 steps as follows:
>
> 0 -> -64/128
> 1 -> -63/128
> ...
> 64 -> 0
> 65 -> 1/128
> ...
> 127 -> 63/128
>
>
> note that 0.5 cannot be reached with this scheme; so sometimes only
> the range 1..127 of the 7-bit number is used in 1/127 steps.
>
> HTH
Thank you Alexandre,
at the moment it's possible to use -64 to +63 by signed two complement
and it's also possible to continue up to +127, assumed the two
complement should cause audible value "jumps".
I simply will connect the Matrix-1000 and then test what happens.
I found a free Windows editor that does provide -63 to +63 (no 0.5
steps) but since I run Windows in VBox, I don't know if I could get a
MIDI output to take a look at the SysEx data.
Another issue are some bit switches, e.g. for a DCO Waveform enable
bit 0 = pulse, 1 = wave and 2 = noise. For the Windows editor it's
possible to turn on pulse, wave and noise at the same time, while I
suspected that if one is turned on, the others should be turned off.
However, I will test it using the editor I've written, with the Matrix I
own.
I hoped somebody who owns a Matrix too does know, too avoid those tests
when I started writing.
If there should be the need to rewrite what already is written, it
wouldn't cause work, the actual work is to copy all parameters from the
manual and to find a way to make the Matrix's matrix clear for the
command line (without a GUI).
It's just a bash script using amidi, from the fact that I need to copy
all parameters from the manual and need to find a way to make the
Matrix's matrix clear without a GUI, the script is finished, so I easily
can test the behavior, whenever I've got some time to do it ;).
Regards,
Ralf
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.
