Hi,
I'm looking into doing some real time MIDI programming with either C++
or Common lisp.
I would specifically not schedule anything but deliver everything as
"play it right now" notes.
Is it necessary to use realtime scheduling the way JACK does?
Or is it ok to use normal "user mode" programs?
Your expert advice much appreciated!
Carlo
Completely agree that SYSEX is where this kind of functionality should reside.
This use of 0x7d is a bit antiquated, no? The reassignment of 0x00 to indicate 3 byte
SYSEX ID means there is a bit more flexibility in the system. Currently the following
are assigned:
0x00 0x00 0xXX American group
0x00 0x01 0xXX American group
0x00 0x20 0xXX European group
0x4X Japanese group (with holes)
0x5X Japanese group (with holes)
0x00 0x04 Japanese group
Getting a registration requires it be paid for, pretty ludicrous for what purports to be
an open standard. I would suggest that Open Source developers should simply take
one of the unassigned values for its own first digit, agree between themselves who
get the next two digits for their apps and SYSEX then be sent with 3 byte ID.
SLab hijacked 0x53 about 10 years ago for this purpose and bolted on a three more
digits for personal identification and there is little reason why this should not be done
again, this time in line with the current MMA SYSEX ID defs as above? If open source
goes and squats on 0x7d then everybody can go and haggle over which app gets the
next two digits.
There is probably going to be some complaints that SYSEX require an extra two
bytes and how that is going to degrade system performance at 31.25KHz, which
probably needs a pre-canned response as it is a non-issue.
This discussion is perhaps better aimed at LAD rather than LAU: LAU justs wants it
to work, LAD can horsetrade on the details.
It is possible that the MMA will take an issue with this since it does not actually fit
within the new SYSEX ID specs (0x7d has not been assigned in the new definition)
but I am pretty sure that if open source applications restrict themselves to their own
set of second and third digits then the MMA will not be so daft as to assign that
number to any manufacturer. For the apps that eventually go commercial then
it is their job, as a part of the commercialisation, to formally request their own ID
from MMA and then to recognise both of them if desired - the MMA assigned one
thanks to paying $$$ for the number, and the squatted ID for compatibility purposes.
Now, to tie this back into the original subject: this does not really help with assigning
MIDI controllers back to app controls as now the surface has to be configured to
generate more complex SYSEX messages, neither easy nor even possible with some of
them, but the argument of applications getting screwed by using the same number
is actually very easy to avoid, admittedly as long as it is done unanimously. Perhaps
linuxaudio.org might want to pick up the gauntlet of assigning the open sourced
digits?
Regards, nick
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
> Date: Mon, 5 Oct 2009 19:19:17 +0200
> From: fons(a)kokkinizita.net
> To: linux-audio-user(a)lists.linuxaudio.org
> Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
>
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
>
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a commercial
> > design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
>
> Ciao,
>
> --
> FA
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
> Date: Mon, 5 Oct 2009 19:19:17 +0200
> From: fons(a)kokkinizita.net
> To: linux-audio-user(a)lists.linuxaudio.org
> Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
>
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
>
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a commercial
> > design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
Hello *,
I am electronic engineer and used the AD1983, AD1984 and AD1988 in some
of my projects. Unfortunately Analog Devices is droping the porduction
next month and there is no replacement.
Please, can someone recomment other manufacturers for High Definition
Audio CODECS which works PERFECTLY with Linux/ALSA?
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/> Michelle Konzack
<http://www.can4linux.org/> Apt. 917
<http://www.flexray4linux.org/> 50, rue de Soultz
Jabber linux4michelle(a)jabber.ccc.de 67100 Strabourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886 Tel. FR: +33 6 61925193
Hi,
I am writing a ladspa host, some kind of modular synth with a python front-end.
In terms of the scheduling algorithm, I was just going to do a topological sort
and then run each plugin from the sources to the sinks. If there is a loop (does
this even make sense?), well i'm not sure what to do there, perhaps it is up to
the script to specify the order.
The other thing I noticed is that plugins are expected to completely fill and/or
drain their buffers (ports). Doesn't this mean it's impossible to make a resampling
plugin with LADSPA ?
Simon.
Fall is upon us.
Summer is gone. Trivial speaking, as it marks yet one's another
birthday, mine that is. It also marks the approaching bankruptcy of this
funny F&D release code-names. One can also think as the last and stable
release before a probable next generation do break all loose. Automation
and full MIDI control is popping up over the horizon. So take all
children home and be prepared for the worst. Nah, don't be that afraid.
With some help from good friends, everything can and shall be arranged.
No second thoughts. No hard feelings. Meanwhile...
Qtractor 0.4.3 (fussy doula) released!
Release highlights:
* Audio send/return aux. inserts (NEW)
* Mixer peak meters gradient eye-candy (NEW)
* MIDI System Exclusive (SysEx) setup manager (NEW)
* MIDI Playback/Queue timer resolution option (NEW)
* MIDI Instrument definitions from SoundFont 2 files (NEW)
* MIDI Output bus default instrument (NEW)
* Buses dialog manager update (FIX)
* Plugin references by label (FIX)
* First audio metronome beat/bar (FIX)
* Ghost clip selections (FIX)
* Overlapping MIDI clips (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3.tar.gz
- source package (openSUSE 11.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.sr…
- binary packages (openSUSE 11.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.x8…
- binary packages (Ubuntu 8.04 LTS):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu804_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu804_…
- binary packages (Ubuntu 9.04):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu904_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu904_…
- user manual (ever still outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- External preset files are not removed nor deleted from the file-system
anymore.
- Connections support for UTF-8 encoded client/port names.
- Force track and clip properties dialog widget to be modal as it should
from their beginning dawn.
- Audio effect send/return aux. inserts are implemented as special
pseudo-plugins (Plugins/Inserts).
- Reset play-head position on auto-backward and keep playback rolling
when continue past end transport option is not set.
- MIDI clip editor (aka piano-roll/matrix aditor) gets better on the
virtual piano keyboard eye-candy side of things ;).
- Plugins are now also referenced by label, avoiding plugin index
clash/misses eg. when plugin object file/path changes or is moved
externally.
- Keyboard focus is now cleared/reset from the main toolbar time and
tempo spin-boxes when editing gets finished (eg. Enter key is pressed).
- First audio metronome beat/bar now played back correctly (fixes bug
#2841437).
- Client to/from port (dis)connections now found consistent as good
ol'QjackCtl behavior (fixes bug #2834657).
- All dirty open MIDI clip editors are now prompted to save before the
main application closes (fixes bug #2835516).
- Mixer level meters get their long deserved gradient look.
- Fixed any ghost clip selections that were haunting the main track
view, specially after undo/redo.
- Increased tolerance on reading corrupt MIDI files (SMF).
- A MIDI SysEx manager is being finally introduced, in some primordial
rather basic form though. MIDI System Exclusive (SysEx) event strings
may now be freely assigned to MIDI output buses only, allowing for
proper setup of external outboard MIDI equipment. Each bus may have an
unlimited SysEx queue that gets sent out on every connection change (see
View/Buses.../MIDI/SysEx...).
- A default MIDI instrument name may now be assigned to any MIDI output
bus (see View/Buses.../MIDI).
- More legacy headers, stdio.h and stdlib.h, are yet again necessary to
build with gcc/g++ >= 4.4 (as patch noted by Alexis Ballier on Gentoo
bug report #274168, thanks).
- Bus manager dialog (View/Buses...) gets new columns on the left pane
buses list as for displaying number of channels and bus mode.
- Crash when updating bus probably fixed (bug #2811630).
- Fixed glitch displaying beat snap/grid lines on MIDI clip editor,
incidental to clips located at absolute zero time.
- Overlapped MIDI clips were rendering garbled note events to DSSI/VSTi
plugins, now fixed.
- New MIDI Playback/Queue timer (resolution) option is now available
(see View/Options.../MIDI).
- MIDI instrument definitions may now be imported from plain SoundFont
files.
Cheers && Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc at rncbc dot org
http://www.rncbc.org
On Monday, October 5, 2009, Fons Adriaensen wrote:
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a
> > commercial design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
The only devices or programs that would be screwed are those bad or poorly
designed/written.
In addition to the manufacturer ID, there should be enough additional bytes to
uncertainly identify a particular model among others using the same
manufacturer ID. The device (soft in this case) receiving a message should be
able to distinguish between legitimate and spurious messages using the model
ID bytes, checksums and/or some other mechanism.
Regards,
Pedro
Hi,
Many thanks for all feedback on my original posting about what
features you would like to see in an open midi controller...
Based on your "requests" I've started experimenting a bit with adding
rotary encoders and a 20x4 lcd display. I've changed to a more
powerful (but still cheap and easy to work with) microcontroller
atmega128 (from atmega16). If you're not familiar with
microcontrollers you might be familiar with the arduino platform which
also uses an atmega (but the lesses atmega168).
Now to my question: Does anyone have some sample velocity curves, like
a mapping from key velocity to midi velocity for different instruments
(grand piano etc)? There doesn't seem to be any convention on how to
handle velocity data?? Does some synths expect linear mapping and does
the "mapping" in software??
--Albin
Hey everyone.
I hope there is some bright minds on this mailing list who can help me.
EMU1212 output 4 differen stereo signals throug ADAT plauying 4 different
sound streams simultasniosly.
The card is installed and alsa recognises it.
aplay -l lists three devices on card 0
device 0 has 32 subdevices.
device 1 is missing
device 2: has 8 subdevices and is named something with FX controller
Device 3 har 1 subdevice
*sury i dont have the real output at the monet*
In alsamixer (playback) I can select a souce for each of the 2 analog
outputs and each of the 8 ADAT outputs from ADAT0-ADAT7
The sources include DSP0-DSP31 and ADAT0-ADAT7 and some more
Natually i think that the 32 subdevicec in device 0 coresponed to the 32
DSP's in ALSA.
But no matter which of the subdevices i try to guide mplayer ot aply
through, it only plays through the sam DSP's
DSp 0 and DSP1 are respectivly left and rigth channel, dsp 6 and 7 is a
player e damped signal of one of dsp0 or ds1 and dsp8 is also playing one of
DSP1 and 2 undamped though.
the rest of the dsp's does not rout any music unless the souround volume is
turned up.
I Testeed this by listning on all the diferens outputs analog 1 and 2 and
the 8 adat channels while chagin through the diferent sources.,
I can sucessfully send sound from DSP1 and or = to each of the outputs and
therefor the physical output is working fine.
But i am not able to use other DSP than 0 and 1 dispite what commands I give
mplayer.
e.q. mplayer -ao alsa:device=hw=0.0.x MUSIC_FILE
I have tried combinations and all the devices
device 2 and 3 returns an device error.
What can I do ?
Humm, than that seems to be the reverse of what we would expect,
that must be then probably because of the missing samples.
If samples were not missing (say
samples from the two channels got distributed between four
channels) then it should go up in pitch, because each channel
would run through the entire data twice as fast, similarly
to what would happen if a mono file was opened as stereo.
If on the other hand you were opening a stereo file as mono,
then the pitch would go down (with some distortion possibly).
Maybe that is what is happening, your stereo file became 4
identical mono tracks.
Victor
----- Original Message -----
From: "Raymond Martin" <laseray(a)gmail.com>
To: "victor" <Victor.Lazzarini(a)nuim.ie>
Sent: Monday, October 05, 2009 10:39 PM
Subject: Re: [LAD] Half speed audio playback issue
> Hi Victor,
>
>> I thought something like that was happening. But I'm curious: if a
>> 2-channel file is played over 4-channels it should go up an octave,
>> should
>> it not? You'd
>> have half as much data for 4 channels as you'd have for 2 channels and so
>> it would seem like it's going faster? Or my reasoning is wrong somewhere
>> (it could
>> well be, I often get things like that mixed up)?
>
> Since you have half as much data your processing (e.g., D to A conversion)
> will interpret this as being at half the rate. Perhaps like it seeing
> every
> second sample, with a blank one in between them, that could lead to
> interpolation that results in a signal at half the frequency. Sort of like
> every second sample is missing (in my case, two of every four are going
> to unused channels). I'm not too fresh on the details presently, but it
> is something this is easy to find mentioned in a standard DSP book.
>
> Best regards,
>
> Raymond
Hi everyone,
Just a word to say that Csound 5.11 is out now. Here is
John ffitch's official announcement.
Victor
======================================================
many of you may have heard the rumours, but it is true, Csound 5.11 is
now released and available from Sourceforge
The release notes are below; the notes at SF are missing GEN49
So, on with 5.12; we await the requests with interest...
==John ffitch
------------------------------------------------------------------------
Notes for 5.11
==============
New Opcodes:
tabsum to sum sections of ftables
p5glove -- not working very well yet
MixerSetLevel_i -- an init-time only version of MixerSetLevel
wiimote opcodes to allow games controller to be read directly in
Csound.
mp3in -- like diskin but reads MP3 files
doppler -- details to follow
filebit -- reports bit size of files
New Gen:
None (well actually there is a gen49 to read mp3 files)
Modified Opcodes and Gens:
Added rounding bin code to pvsscale
Added NP2 support for ftload and ftsave
GEN23 totally rewritten to be more consistent in what constitutes
a separator and comments. (Still no /* */ comments)
Bugs fixed:
Use of automatic numbering of ftables reuses table numbers
seed with positive argument was wrong
sprints with an empty string printed wrong data
mute now works with both numeric and named instruments
Comments in new parser fixed
Byteorder in loading files fixed
Small fixes in diskin, and in tablexkt
System Changes:
Revised Windows installer
SConstruct now builds completely independent shared libraries
for Python, Lua, and Java wrappers.
New Parser almost usable
Redrawing of graphs fixed so that only selected ones get redrawn.
RT-alsa more forgiving on near sample rates
It is possible to have the score generated by an external program
rather than using standard score format using
<CScore bin="translater"> to call the program translater on the
score data
lpc_export fixed
Removed limit on macro names length
PMAX, the number of arguments to a score event has been reduced
by 2, and an overflow system introduced so GENs can have
arbitrary numbers of arguments.
API:
Increased API version to 2.1.
New API function pointer ldmemfile2withCB() which is
a version of ldmemfile() allowing a callback to be set and called
exactly once to process the MEMFIL buffer after it is loaded.
csound->floatsize set; zero in earlier versions
GetChannelLock added
Internal:
usual collection of gratuitous minor changes, layout and comments
*end*