Hi!
Does anybody know a freehand notation system (no matter if free or commercial)
beside this one: http://www.freehandsystems.com ? Or do you probably know
open source software system(s) that could reach the same features with a
*reasonable* low amount of work?
CU
Christian
jack_mixer version 3 released.
jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s
hardware counterparts. It has lot of useful features, apart from being
able to mix multiple JACK audio streams.
Changes since version 2:
* Detect NaNs
* Dont mix nan sample and next samples in current jack frame (only messed channel)
* Show NaNs to user (abspeak goes red and shows NaN)
* Reset channel NaN status on abspeak reset
* Switch to autotools (prepare for JACK MIDI support)
Homepage with screenshots: http://home.gna.org/jackmixer/
Download: http://download.gna.org/jackmixer/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Rejected, OK ... Sorry but;
Really, this worked the first week after migration, what's up now?
Is it that it took me this long to respond to the Berlin-TU event?
please, I am an old man and can't move my braincells - let along my
email accounts - that fast anymore .. :-D
/jens m
--
hi,
The buzztard team has release version 0.2 "sunrise" of its buzz-alike music
composer.
This version has lots of UI usability improvements, bug fixes, more instant
apply settings and introduces some interactivity features (interaction
controller and upnp playback controller).
The gstreamer extension modules got two new interfaces for presets and help.
A Fluidsynth generator plugin has been started.
project-page: http://www.buzztard.org
screenshots: http://www.buzztard.org/index.php/Screenshots
downloads : http://sourceforge.net/project/showfiles.php?group_id=55124
buzztard core developer team
--
http://www.buzztard.org
Hi,
About a week ago, out of boredom, I started working on
little retro-styled '80s kind of video game, written
in a pretty simple-minded way with gnome, and the graphics
done just by using line drawing primitives. It was just
something to do, I didn't imagine it would amount to anything.
Well, it's turning out surprisingly well (not great, but
better than I was expecting.) So now I'm thinking to add
sound, but apart from some MIDI programming, I really haven't
done any audio programming before (unless you count some
Extended BASIC code on a ti99/4a back in the '80s -- and
nobody would count that.)
So, I found libao ( http://xiph.org/ao/doc/ ) which looks
nice and simple, and the sample program I tried
( http://xiph.org/ao/doc/ao_example.c ) worked right off
the bat, and the idea of synthesizing my own sounds by
constructing waveforms using sine waves is appealing for
a retro styled app like mine (though I have no experience
doing that and only a vague memory of trigonometry), but
I wonder about how to mix sound (add the waveforms, I guess)
and construct them on the fly (or trigger pre-computed
chunks of audio).
In the example code, it plays a one second chunk of audio
with one library call initiating the playback.
So, I imagine that for a game, in order to satisfy the
real-time-ish requirements, I'd instead construct maybe
1/10th or 1/20th second chunks, which would be queued up
in my program for playback, and whenever some event happens
which demands some sound be produced _right now_ (like the
user presses the "fire" button, and so needs some bleeping
laser gun sounds to be produced) I would then start adding
(arithmetic addition) laser-gun-waveform-data into whatever
chunks were already in the queue, and so out would come
the sound...
Does that seem like a reasonable approach?
By chopping the sound up into 1/10t or 1/20th second chunks,
am I apt to cause distortion of some kind?
Is there some other library I might be better off with?
(I looked at SDL, but it seems heavily tilted towards
graphics, and I already have the graphics stuff going alright
under just regular old gnome.)
I might also want to playback some ogg encoded files for maybe
prerecorded sound effects and music to be mixed
in with the synthesized sound effects. libao won't do that by itself, but
I think there are some other libs on xiph.org that do that, but
I'm not sure how well they'd accomodate mixing random bits of
sound in with them.
Saw this: http://www.underbit.com/products/mad/
fixed point mpeg decoder library... Not sure how
easy it'd be to mix in other sounds with its output.
Maybe just decode into memory buffer.
Anyway, just looking for suggestions, esp. if what
I've described so far seems wrong.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Keyboard Magazine carries an article this month about Linux Audio:
http://www.keyboardmag.com/story.asp?sectioncode=29&storycode=17973
-8<--------------------------------
You might think there’s no way a free operating system written by
volunteers could compete when it comes to music production. But in the
past couple of years, all the tools you need to make music have arrived
on Linux.
[...]
hello everyone
One thing that draws my attention is MIDI playing. So far, by using
Timidity and ALSA, I tried to play several MIDI files and it is hard for
me to notice any lag. I only noticed delayed notes when system is under
busy load (I run CPU bound program with nice level above -9).
Things I'd like to discuss are (I am sorry if they sound dumps
because I still study all these stuffs):
1. Is it me just who is not professional enough to notice any difference
when using various kernel HZ setting (smooth playing on HZ=x, not so smooth
when HZ=y and so on)? Or, does the delay fall in non-human-perceptible
range thus normal human being can not see the difference?
2. Is it correct that recent ALSA sequencer use RTC as source timer thus
kernel HZ is no longer relevant in the sequencer's point of view?
3. Related to the system load I mentioned above, I think I was seeing
scheduling latency and not really a timing latency. If that's correct,
could you kindly suggest what I must do to show that MIDI timing does
have any relation with HZ?
4. I am also thinking about MIDI recording as a way to show HZ effect.
Since I don't have any MIDI devices (but I plan to buy one if it's
really neccessary), I'd like to explore the correctness of this idea
first. Do you think it is really a proper experiment in HZ test context?
Thank you in advance for your help and attention and I am looking
forward to read your feedback. Sorry if it has been discussed before,
but I fail to completely research it until today.
regards,
Mulyadi
PHASEX-0.10.1 is a buildfix and bugfix release, highly recommended for
anyone who currently has 0.10.0. Here's the changelog:
* Fixed delay buffer size crash bug.
* Rebuilt config.h from configure.ac (fixes undefined PHASEX_DIR).
* Added engine thread cancellation point.
* Changed order of setting up JACK callbacks (might help jackdmp?)
* Moved main sample rate init code from samplerate callback to jack thread.
* Fixed oversampling mode.
* Fixed typo on bank.c.
* Disabled debug output in help.c.
* Added --enable-debug= option to configure.
* Fixed volume of bassy-plucked-lead and zeroed input boost on all
patches.
I'm still looking into issues with older versions of GTK-2.x. It looks
like the current minimum GTK version is somewhere around 2.6 or 2.8. Most
of the non-FC6 build issues appear to be related to this.
Reports for SMP, non-FC6, and jackdmp systems would be very helpful, as
these are the things I can't test right now.
Thank you all for the valuable feedback! I'm already getting a good sense
of what's needed most and where things should go in the project roadmap.
Based on responses so far, the roadmap up to 0.20.0 should look something
like this:
0.11.0 Bugfixes, buildfixes, code cleanups, GUI aesthetic issues.
0.12.0 Rework patch bank system to support alternate patch dirs and
include a patch chooser.
0.13.0 LASH support.
0.14.0 Fine-tune threads (remove locks), optimize dsp code more.
0.15.0 New small features and simple GUI enhancements.
0.16.0 Implement LFO clock-sync for MIDI clock and JACK transport.
0.17.0 JACK MIDI support.
0.18.0 Multitimbral or multiple instance support.
0.19.0 Overhaul parameters to add generic ctlr-float conversions
and add mod-matrix (w/ velocity and aftertouch handling).
0.20.0 OSC and DSSI support.
Cheers,
--ww
--
/* William Weston <weston(a)sysex.net> */
William Weston <weston(a)lysdexia.org> writes:
>> (gdb) bt
>> #0 0xb7f39410 in __kernel_vsyscall ()
>> #1 0xb7e3acf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> #2 0x080518cc in engine_thread (arg=0x0) at engine.c:1125
>> #3 0xb7e383dd in start_thread (arg=0xb4df9bb0) at pthread_create.c:261
>> #4 0xb774bc8e in clone () from /lib/libc.so.6
>> (gdb) The program is running. Exit anyway? (y or n) y
>
> Hmmm... I can't seem to duplicate this one. Are you running SMP, by
> chance? I've added a thread cancellation point in 0.10.1 to see if that
> helps.
Actually yes, a SMP system. I'll try on uniprocessor system too (hope
this evening).
>> Have you considered using widgets from PHAT? I beleive there is no
>> difference between knobs you use and phatknobs. If there are
>> improvements chances are they shoud got in PHAT version too.
>
> I've looked at PHAT, but decided to start off with the basic gtkknob code
> that everyone's been passing around so I could hack on it for a while. I
> have added one modification that's not in the PHAT version: middle click
> centers a knob.
I recently added middle click to PHAT fanslider because I needed "reset
to default" too, so I'd be glad if we have this for phatknob too.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Thu, 2007-05-03 at 19:52 -0700, William Weston wrote:
> On Thu, 3 May 2007, Lars Luthman wrote:
>
> > Very nice sounds. Since you asked for feedback, here is some:
> >
> > * the whole program crashes for me when I pull down the File or Patch
> > menus or try to close the window, with lots of Gtk error messages
> > about invalid style objects. If I change line 241 in gtkknob.c from
> >
> > widget->style = gtk_style_attach(widget->parent->style, widget->window);
> >
> > to
> >
> > widget->style = gtk_style_attach(widget->style, widget->window);
> >
> > it doesn't crash any more. Other behaviour seems to be identical.
>
> Wow... thanks! This change will be put in 0.10.1.
> BTW, what GTK version are you running?
2.8.20 on Debian Lenny.
--ll