There have got to be some decent libraries for this, but it seems like
almost every linux midi app has its own code for reading and writing
midi files. What's up with that? What do you guys recommend?
Hi.
IIRC, I already told of my plans to write a midi.el for Emacs Lisp to
handle MIDI file data in Emacs directly on LAD. This idea has been recently
supersceeded by something much more powerful, the marriage of
CommonMusic and Emacs. SLIME is the key, SLIME makes it possible!
I've been recently learning CommonMusic again, and discovered that
it already can nicely handle MIDI file data (and much more). So reimplementing
the wheel in yet another lisp dialect doesn't seem like a very
useful exercise. What I can do, actually, is bring
Emacs and CM a little more together, using SLIME. This effectively means
that now, I can control SC and CM from Emacs, very easily.
Its all a bit of puzzlework for now, but as soon as we/I worked
out some ways to make things stick more together, I think this is
going to be a very powerful combination.
;; Example Emacs Lisp code:
(require 'slime)
(defun cm-eval (form &optional callback)
"Eval FORM in the CM package. If CALLBACK is a function, pass result
to it as soon as evaluation is finished (async). Otherwise, return
result."
(setq form `(swank:interactive-eval ,(format "%S" form)))
(if callback
(slime-eval-async form `(lambda (arg) (funcall ,callback (read arg))) "CM")
(read (slime-eval form "CM")))))
(defun cm-get-midi-notes (filename)
"Return all notes in a midi file in sequencial order."
;; Not very useful in real world, just a demonstration
(cm-eval
`(note (nreverse (fold-objects 'cons
(events (import-events ,(expand-file-name filename)) (new seq))
()
:slot 'keynum :class 'midi))))))
;(cm-get-midi-notes "~/music/Bach_Suite_no4_BWV1006a_Prelude.mid") =>
; (E2 E5 EF5 E5 B4 AF4 B4 E4 FS4 E4 EF4 E4 ...)
;(length (cm-get-midi-notes "~/music/Bach_Suite_no4_BWV1006a_Prelude.mid")) =>
; 1741
>From here on, it should be fairly trivial to integrate SC and CM since
both can be easily talked to from within Emacs programmatically.
One thing I'd like to attempt for instance is a tree-widget based browser
for CM objects.
Thoughts? More code? If you are interested in this, send private mail.
--
CYa,
Mario
Jack has finally reached version 0.100.0. In brief, more functions
for getting latency statistics, better thread handling, and a more
verbose way of connecting to the jackd server.
This new function is jack_client_open(). From the documentation:
Open an external client session with a JACK server. This interface
is more complex but more powerful than jack_client_new(). With it,
clients may choose which of several servers to connect, and control
whether and how to start the server automatically, if it was not
already running. There is also an option for JACK to generate a
unique client name, when necessary.
Jack-0.100.0 is available from http://jackit.sf.net, although a new
website is in the works.
***CHANGES***
Rewritten coreaudio driver
Switched to ALSA-1.0 API
Added functions jack_client_create_thread(),
jack_get_max_delayed_usecs(), jack_reset_max_delayed_usecs(),
jack_internal_client_handle(), jack_internal_client_load(),
jack_get_internal_client_name(), jack_internal_client_unload(),
jack_get_xrun_delayed_usecs(), jack_client_open(), and
jack_get_client_name(). See documentation for details.
Removed functions jack_set_server_dir(), jack_create_thread()
Added header file <jack/statistics.h>
ALSA, OSS, and CoreAudio drivers now have -I/-O options for setting
systemic latency.
Added client request type RecomputeTotalLatencies
Compiles and runs on MacOSX 10.4
Change the way threads get RT scheduling. it is now requested by the
thread rather than assigned by the thread's parent. in cases where
capabilities are used, the child is also given capabilities so that
it can release + re-acquire RT scheduling as needed.
Prevent watchdog from killing anything is JACK is freewheeling.
And of course tons of bug fixes.
Sincerely,
Taybin Rutkin
Disk IO priorities have been discussed on the list before, and they are
now in the mainline kernel (search LKML for "IO priorities" for
details). I think they're only supported by the CFQ scheduler.
This might be fun for someone to experiment with, I'm sure any HDR
application would like this feature.
Lee
by Kjetil Svalastog Matheussen <k.s.matheussenï¼ notam02.no>
http://www.notam02.no/radium/
INTRODUCTION
------------
E-radium is Radium and a special version of E-UAE.
Radium is a midi music editor for the amiga and E-Uae is an amiga
emulator.
CHANGES
-------
0.61c -> 0.6d:
-Increased amount of Z3-memory from 32 to 64. Also increased the amount of
chip-mem from 2 to 8 to let there be more time to quit/save after getting
a warning about too little memory. For now, this seems to work...
-Lowered the keyboard repeat rate a bit.
-Fixed make install
-Use standard mouse pointer.
-Upgraded Radium from 0.61c to 0.61d:
-Added scroll-mouse support. Scrolling up is exactly the same as pressing
arrow up, and scrolling down is exactly the same as pressing arrow down.
Has anyone written code for, or even just seen, a 2-D slider widget?
What toolkit was it in? Do people around here prefer QT to GTK+, or
vice versa, and does anyone use FLTK, or something else?
I think the ideal widget would allow the user to click or
click-and-drag a cursor around the 2-D area, returning x and y
coordinates of course; and would allow a bitmap to be displayed
underneath the cursor; and would allow some way to constrain the
cursor movements (eg within a circular area inside the widget).
Such a thing would be great for lots of audio applications, like
controlling filter cutoff and resonance at the same time. That's what
I'll be doing, only a bit more complicated..!
Hello all,
I'm trying to clear up my mind as to what conventions to follow
in a GUI for the actions of zooming in and out e.g. a spectrum
or an impulse response window. It's not the intention to launch
a debate about this, just to collect other people's ideas.
The accepted model for scrolling is that the user 'moves'
a *clipbox* that determines what part of the *content* is
visible. For example, when you drag a scrollbar to the right,
the clipbox moves to the right. What actually happens of course
is just the opposite: the clipbox remains static on the screen,
and the content moves to the left.
The other model is used as well, for example Acrobat Reader
lets you drag the content directly.
Now my question: what about zooming ? For keyboard shortcuts,
Ardour uses '+' to zoom out and '-' to zoom in. This is
consistent with the idea that the user modifies the clipbox.
But I still have to think before using it, each time, and I
could easily imagine using '+' to zoom in. In fact I have no
clear preference.
Then there's the questions of icons. If in addition to the
arrows in a scrollbar you would also have small buttons to
zoom in and out, what should they look like ?
Zoom in Zoom out
- +
-><- <->
or the inverse ???
--
FA
Hi!
Today I went downtown to the big store, to buy a few things I need for
other purposes. They sell computer related stuff as well, and I picked
up a gamepad which had an analogue mini joystick buildin. I've always
thoght that gamepads are glorified arrow keys, but that mini analogue
joystick left me wondering ...
Anybody here have had any luck using something like that under Linux?
For the price of only slightly more than a scrollwheel mouse I think
it's a bargain. Could find good use for balancing out parameters in a 2d
space. It has quite a few buttons also that could be useful for
selecting modes.
It is a USB device (great), but the box says only that it works with all
versions of Windows known to mankind ...
It looks like this:
http://www.clasohlson.se/images/products/S/hi/B/326344_X_2004-08-09_121320.…
So, could this be an answer to the budget synthesists need for hands on
control of his linux based softsynths?
mvh // Jens M Andreasen
Here is a patch that got swh plugins built for me on FC4 gcc version
4.0.0 20050519 (Red Hat 4.0.0-8)
the original fails on gcc4 for both use of a removed optimize option
-fmove-all-movables and for declaring an already defined non-static
variable as static.
More on the removed optimization flag here:
http://gcc.gnu.org/gcc-4.0/changes.html
The options |-freduce-all-givs| and |-fmove-all-movables| have been
discontinued. They were used to circumvent a shortcoming in the
heuristics of the old loop optimization code with respect to common
Fortran constructs. The new (tree) loop optimizer works differently and
doesn't need those work-arounds.
--
http://nostar.net/