Re: [linux-audio-dev] oh no ... virtual vocalists ...
> > http://news.harmony-central.com/Newp/2003/Vocaloid.html uck. neat. no. uck. seems like Strange Days (the movie) to me. UCK.
[linux-audio-dev] oh no ... virtual vocalists ...
http://news.harmony-central.com/Newp/2003/Vocaloid.html
[linux-audio-dev] cute idea from the VST world ...
http://www.fxfreeze.com/product.html
[linux-audio-dev] Introduction to building MIDI controllers?
Hi all, I was just wondering if anyone knows of any good resources for an introduction to building hardware MIDI controllers? Any recommendations for books or online references would be appreciated. I've been looking at Digital Projects for Musicians by Craig Anderton on amazon, but the reviews seem to be pretty negative. Any advice? - Adam
Re: [linux-audio-dev] modular synth GUI status?
On Wed, Nov 19, 2003 at 08:30:53PM +0100, Frank Barknecht wrote: > Paul Davis hat gesagt: // Paul Davis wrote: > > supercolliderJames ??? Yes ^ McCartney btw., got OSS last year or so, ported to linux/jack by stefan kersten. martin
Re: [linux-audio-dev] modular synth GUI status?
On Wed, Nov 19, 2003 at 08:03:06PM +0200, Juhana Sadeharju wrote: >Hello. Who of us are working on a modular synth GUI where user >grab&drag modules and connects them with cables? I'm myself >interested in the editor GUI development --- there already >are many modular audio engines, but not particularly good GUIs >(Quasimodo might be an exception if I remember correctly). (cut) Cable GUIs are an anachronism to me, but it is hard to come up with new versatile alternatives :) v
Re: [linux-audio-dev] modular synth GUI status?
Hi, the project http://nmedit.sf.net tries to recreate the editor for Clavia Nord Modular. The progress is slow but steady. I had an idea that we should create a generic module canvas that could be reused by other modular synthesizers. It would handle module visualization, movement, interaction, cable connections, common widgets and so on. XML could be used to configure the canvas for a particular modular synthesizer. Some kind of event model would be used to hook up the canvas with the underlying patch representation. Unfortunately I haven't had the time to specify or implement such a canvas yet. I am not involved in the current GUI effort, which is a direct implementation in java without the generic canvas abstraction. As things look now, the architecture will evolve into a protocol backend and a graphical editor frontend. This means that it will be possible to control the synth through both a text interface and a GUI. Marcus Juhana Sadeharju wrote: Hello. Who of us are working on a modular synth GUI where user grab&drag modules and connects them with cables? I'm myself interested in the editor GUI development --- there already are many modular audio engines, but not particularly good GUIs (Quasimodo might be an exception if I remember correctly). Below is a short list of modular synths. I'm still searching for more. I will mail an updated list later, but at meanwhile you could help me ;-) Regards, Juhana == cut == NameAuthor Has cable-GUI Has script-GUI - Nord ModularClavia Yes No Harmonizer/Vsig Eventide Yes Yes Oasys Korg ? ? Csound Barry Vercoe No Yes Cmusic ? No Yes Quasimodo Paul Davis Yes No PD Miller PucketteYes No PSK ? No Yes jmax? ? ? Nyquist (1) R.B. DannenbergNo Yes SAOL? No Yes ?? Creamware Yes No Arts? Yes No Vaz Modular ? Yes No Reaktor ? Yes No Tasman ? ? ? SyncC modular ? ? ? BlockCompiler Matti Karjalainen No Yes == cut ==
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
Stefan Nitschke wrote on Wed, 19-Nov-2003: > tmpfs /tmp/ramdisk/ tmpfs size=5M,nr_inodes=1k,mode=777 0 0 > > to fstab:) > > Which RAM disk size is OK for jack? You don't need to even specify a size for a tmpfs. But jack doesn't even use any space in there, they are all sockets or pipes. jlc
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
BTW: There is a prefech bug on AMD processors - try to run it recompiled with less optimization, newer kernels have workarounds. Another thing to try is to run memtest86 (SuSE has it in Lilo menu) let it run for a while (full night) I solved the freezing problem by compiling jack to use a tmpfs for its temp files! BTW to get low latency working on that machine I had to switch down from IDE DMA100 to DMA66 mode. Now I am sure that there is a nasty bug with my ASUS A7V-266E board. Nice to see that it is solved by just adding: tmpfs /tmp/ramdisk/ tmpfs size=5M,nr_inodes=1k,mode=777 0 0 to fstab:) Which RAM disk size is OK for jack? - Stefan _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: [linux-audio-dev] modular synth GUI status?
Hallo, Juhana Sadeharju hat gesagt: // Juhana Sadeharju wrote: > Hello. Who of us are working on a modular synth GUI where user > grab&drag modules and connects them with cables? I'm myself > interested in the editor GUI development --- there already > are many modular audio engines, but not particularly good GUIs > (Quasimodo might be an exception if I remember correctly). Actually although I made some of the old buttons in Quasimodo I now have come to dislike this kind of GUI and much prefer the free organization that environments like Pd or jMax offer. So the term "good GUI" is highly personal. Pd for example might not be good looking but it has some features that are really unique, but a bit hard to describe in words like "patch painted GUI elements" or "swallowed, reusable see-through GUIs". Expecially the last feature (called "graph on parent" in Pd lingo) is a wonderful invention that all other modular synth authors need to copy. (Max/MSP has a similar feature with its bpatcher) ciao -- Frank Barknecht _ __footils.org__
Re: [linux-audio-dev] modular synth GUI status?
Hallo, Paul Davis hat gesagt: // Paul Davis wrote: > >Below is a short list of modular synths. I'm still searching for > >more. I will mail an updated list later, but at meanwhile you > >could help me ;-) > > supercolliderJames ??? Yes > > btw, "script GUI" is a bit of confusing term :) I think it's very confusing. What does it mean? I think, Pd surely has GUI scripting, but I don't know what it is exactly... ciao -- Frank Barknecht _ __footils.org__
Re: [linux-audio-dev] oss driver for jack 0.90 rev3
>On Wed, 2003-11-19 at 00:56, Paul Davis wrote: > >> if you used poll(2) or select(2), you could do simultaneous waits on >> each direction, regardless of whether they use different devices or >> not. you'd then reduce the context switches and the overhead of >> synchronize(). > >Context switches are not problem when thread's main function is to sleep >on blocking descriptor. And synchronize() has minimal overhead on system >which have futexes and very small in any case. Sleeping on system call >(on waitqueue) doesn't take any noticeable amount of CPU time. This >works especially well on SMP machines. OK, your choice. From my perspective, 1 context switch is on the order of 2-6% of the available CPU cycles for a 64 frames-per-interrupt configuration. And sleeping in two threads on what in just about every case will be one piece of hardware with synchronized playback and capture streams seems like a waste of resources to me. 99 times out of a hundred, or more, the "ready" bit on a task is set from the interrupt handler, and it will set both the playback and capture waitqueues. as a result, you now have to wake up two threads when one would do. you're accomplishing nothing that i can see, other than adding a certain kind of theoretical elegance in your code. and theoretical elegance is for the API, not the implementation :) >Not all OSS Lite drivers support poll() or select(). :( >> i also note that you're also not using mmap, resulting in extra >> copying of significant quantities of data on every cycle for >> multichannel cards. the cpu cycles for this can be significant when >> you get down to very low latency on hammerfall cards, for example. > >Memorymapping buffers of fast running devices is problematic. >(Soundcards are relatively slow however.) Also the pagefault handler >takes some time. there are no pagefaults in a realtime JACK system. all code is pinned in physical RAM. >Another point is that normal gcc memcpy() is significantly slower >compared to copy_to/from_user() on modern hardware. do you have a URL i can read about this? >Third is that mapping DMA buffers of 32-bit cards to memory space of >64-bit processors is another story. If the driver is mapping some >secondary buffer allocated from vm then it's different. ALSA seems to be handling it perfectly OK so far. >I don't have have any control on jack, so I'm not going to tie myself up >on something which needs unspecified amount of work. I'll merge it into CVS after thanksgiving (nov 27th) here (first time i'm likely to have the time). --p
Re: [linux-audio-dev] modular synth GUI status?
On Wed, Nov 19, 2003 at 08:03:06PM +0200, Juhana Sadeharju wrote: > Hello. Who of us are working on a modular synth GUI where user > grab&drag modules and connects them with cables? I'm myself > interested in the editor GUI development --- there already > are many modular audio engines, but not particularly good GUIs > (Quasimodo might be an exception if I remember correctly). > > Below is a short list of modular synths. I'm still searching for > more. I will mail an updated list later, but at meanwhile you > could help me ;-) Have a look at alsamodular.sf.net It has ATM a modules + cables GUI, and we (Matthias Nagorni & me) plan to include a scripting system somewhere in the not too distant future. -- Fons
Re: [linux-audio-dev] modular synth GUI status?
>Below is a short list of modular synths. I'm still searching for >more. I will mail an updated list later, but at meanwhile you >could help me ;-) supercolliderJames ??? Yes btw, "script GUI" is a bit of confusing term :) --p
[linux-audio-dev] modular synth GUI status?
Hello. Who of us are working on a modular synth GUI where user grab&drag modules and connects them with cables? I'm myself interested in the editor GUI development --- there already are many modular audio engines, but not particularly good GUIs (Quasimodo might be an exception if I remember correctly). Below is a short list of modular synths. I'm still searching for more. I will mail an updated list later, but at meanwhile you could help me ;-) Regards, Juhana == cut == NameAuthor Has cable-GUI Has script-GUI - Nord ModularClavia Yes No Harmonizer/Vsig Eventide Yes Yes Oasys Korg ? ? Csound Barry Vercoe No Yes Cmusic ? No Yes Quasimodo Paul Davis Yes No PD Miller PucketteYes No PSK ? No Yes jmax? ? ? Nyquist (1) R.B. DannenbergNo Yes SAOL? No Yes ?? Creamware Yes No Arts? Yes No Vaz Modular ? Yes No Reaktor ? Yes No Tasman ? ? ? SyncC modular ? ? ? BlockCompiler Matti Karjalainen No Yes == cut ==
RE: [linux-audio-dev] plugin GUIs
Maybe this is off topic and I know there are plenty of GUI toolkits but I just thought I would throw it out here. I have written my own GUI toolkit over the last few years and it is quite useful and I would be willing to share it for further development for those folks that are inclined to incorporate it into their software. It is not nearly as complex as these other GUIs but it is quite comprehensive and has an exandable event model. If interested shoot me an e-mail and I can discuss it and basically build it into anything you need. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Maarten de Boer Sent: Wednesday, November 19, 2003 9:06 AM To: The Linux Audio Developers' Mailing List Subject: Re: [linux-audio-dev] plugin GUIs [snip: paul davis' gtk embedding example] well, looking at your code, i am not really sure if this is what you mean, but the attached code shows how to embed an existing X11 window inside a fltk window (run it, find out the XId of any existing window (with xwininfo), and enter it in the text input. it does not matter if the existing window is gtk, qt, motif, fltk or plain X. however there are some problems, if you move the parent window: motif menus are opened at the position where the window was first embedded, and for fltk menus even the menubar buttons itself. if anybody has a suggestion on how to solve this... maarten g++ embed.cxx -lfltk
Re: [linux-audio-dev] oss driver for jack 0.90 rev3
On Wed, 2003-11-19 at 00:56, Paul Davis wrote: > if you used poll(2) or select(2), you could do simultaneous waits on > each direction, regardless of whether they use different devices or > not. you'd then reduce the context switches and the overhead of > synchronize(). Context switches are not problem when thread's main function is to sleep on blocking descriptor. And synchronize() has minimal overhead on system which have futexes and very small in any case. Sleeping on system call (on waitqueue) doesn't take any noticeable amount of CPU time. This works especially well on SMP machines. Not all OSS Lite drivers support poll() or select(). > i also note that you're also not using mmap, resulting in extra > copying of significant quantities of data on every cycle for > multichannel cards. the cpu cycles for this can be significant when > you get down to very low latency on hammerfall cards, for example. Memorymapping buffers of fast running devices is problematic. (Soundcards are relatively slow however.) Also the pagefault handler takes some time. Another point is that normal gcc memcpy() is significantly slower compared to copy_to/from_user() on modern hardware. Third is that mapping DMA buffers of 32-bit cards to memory space of 64-bit processors is another story. If the driver is mapping some secondary buffer allocated from vm then it's different. > i didn't really sense an answer to my question about your willingness > to maintain your OSS driver in the face of any future changes in > JACK. if i can get a clear answer on this, i'll make a decision about > adding it to CVS. It depends on how much the jack is going to change, my motivation, time and of course on user demand. All I can say is that I will do it for unspecified time, unless it takes too much time from my actual projects. I don't have have any control on jack, so I'm not going to tie myself up on something which needs unspecified amount of work. -- Jussi Laako <[EMAIL PROTECTED]>
Re: [linux-audio-dev] plugin GUIs
[snip: paul davis' gtk embedding example]
well, looking at your code, i am not really sure if this is what you
mean, but the attached code shows how to embed an existing X11 window
inside a fltk window (run it, find out the XId of any existing window
(with xwininfo), and enter it in the text input. it does not matter if
the existing window is gtk, qt, motif, fltk or plain X. however there
are some problems, if you move the parent window: motif menus are opened
at the position where the window was first embedded, and for fltk menus
even the menubar buttons itself. if anybody has a suggestion on how to
solve this...
maarten
g++ embed.cxx -lfltk
#include
#include
#include
#include
#include
#include
#include
class Fl_Embed_Window:public Fl_Window
{
public:
Window xid_;
Fl_Embed_Window(int ix,int iy,Window xid):Fl_Window(ix,iy,0,0)
{
xid_ = xid;
}
void show(void)
{
XWindowAttributes attribs;
XGetWindowAttributes(fl_display, xid_, &attribs);
if (shown()) {
Fl_Window::show();
return;
}
Fl_X::set_xid(this, xid_);
size(attribs.width,attribs.height);
XReparentWindow (fl_display, xid_, fl_xid(window()), 0, 0);
}
};
void embed(Fl_Widget* widget,void* ptr)
{
Fl_Input* input = (Fl_Input*) widget;
Fl_Window* window = widget->window();
Fl_Window* embedded;
char tmp[256];
int xid;
strncpy(tmp,input->value(),255);
sscanf(tmp,"%x",&xid);
window->add(embedded = new Fl_Embed_Window(0,0,xid));
embedded->show(); // cause the reparent
}
main()
{
Fl_Window window(400,400);
Fl_Input input(0,380,400,20);
input.when(FL_WHEN_ENTER_KEY);
input.callback(embed);
window.end();
window.resizable(window);
window.show();
Fl::run();
}
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
Roger Larsson <[EMAIL PROTECTED]> writes: > But on those audio workstations you have NO problem to make > wrappers suid root. > > * The "audio workstation" case can always be handled. > * The problematic case is "common desktop" where users get a much worse > experience than they should - and it might scare people off. OK, now I see your point. We were working on different problems. I mostly agree, though I much prefer making audio apps setgid `realtime' and not setuid `root'. > I have an idea! > > rt_monitor is running mlockall and I avoided > * dynamic memory allocation > * system calls > - If I split the function into server and monitor (two threads) it > would be even better. > So rt_monitor itself should never get stuck requesting more memory, nor get > stuck in a system call getting stuck on another process requesting more > memory. Sounds like a good idea. -- joq
Re: [linux-audio-dev] ANNOUNCE: QSynth 0.0.1 - Qt interface to fluidsynth
On Wednesday 19 Nov 2003 1:23 pm, Paul Davis wrote: > i'm not going to have time to try it for a while, but i just wanted > to note that i really like the pale yellow/green you use for the > spinbutton backgrounds. Well that's very valuable feedback, thank you. Unfortunately, the colour is just an artifact of the Qt theme Richard was using when he took the snap. Chris
Re: [linux-audio-dev] ANNOUNCE: QSynth 0.0.1 - Qt interface to fluidsynth
> http://qsynth.sourceforge.net > >Requirements are Qt3.1.1 and libfluidsynth. > >Please let us know how you get on with it! i'm not going to have time to try it for a while, but i just wanted to note that i really like the pale yellow/green you use for the spinbutton backgrounds. its very delicious. i have to find a way to use that into ardour somehow... :)
[linux-audio-dev] ANNOUNCE: QSynth 0.0.1 - Qt interface to fluidsynth
[This has been announced on LAA already, but I gather crossposts are expected.] We'd like to announce the first alpha release of QSynth, an attractive Qt front-end to fluidsynth. QSynth is brought to you by Rui Nuno Capela, developer of qjackctl, together with Richard Bown and Chris Cannam of the Rosegarden team. QSynth provides a simple front and configuration interface to the fluidsynth software synthesiser to allow persistent storage of fluidsynth configuration (and soundfonts) as well as providing visual feedback and front panel controls for software synthesiser parameters. QSynth can be used either as a standalone player or in conjunction with any compatible sequencers. For more details, screenshots, mailing list details and to download the source code please visit: http://qsynth.sourceforge.net Requirements are Qt3.1.1 and libfluidsynth. Please let us know how you get on with it! Chris
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
But you do have it recompiled for the right CPU architecture and not only moved? Yes of course. BTW: There is a prefech bug on AMD processors - try to run it recompiled with less optimization, newer kernels have workarounds. I will try that... but I get the freezes only with jack. ALSA applikations run just perfect in rt mode. Another thing to try is to run memtest86 (SuSE has it in Lilo menu) let it run for a while (full night) I will do... and if nothing helps I will get a new mainboard ;-) - Stefan _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
On Wednesday 19 November 2003 01.40, Jack O'Quin wrote: > Roger Larsson <[EMAIL PROTECTED]> writes: > > Problem is - why doesn't most distributions even ship with wrappers suid > > to be able to start the application with SCHED_FIFO/RT/mlock? > > - It is due to risks of local Denial Of Service attacks (intentional or > > unintentional) > > That seems logical, but AFAICT the actual reason is because of a > security hole introduced by CAP_SETPCAP (which was not part of the > original POSIX draft spec). Before this screwup was detected, kernels > shipped with capabilities enabled. > > If an attacker manages to subvert one of the system daemons with a > buffer overflow (sendmail is a frequent target), it can use > CAP_SETPCAP to deny capabilities to other system services that need > them to perform their jobs, including monitoring system security. Yes, lets take a specific example arts (KDE audio) and artswrapper. Artswrapper should be suid root to give arts the desired SCHED_FIFO, that is close to the full function of artswrapper - but still it is not shipped suid root... > > > So with any scheme that opens up these holes you have to deliver a way > > to protect from the downsides. > > Clearly this is desirable. But, for many audio workstations it is > *not* mandatory. But on those audio workstations you have NO problem to make wrappers suid root. * The "audio workstation" case can always be handled. * The problematic case is "common desktop" where users get a much worse experience than they should - and it might scare people off. > > > My monitor protects from CPU overuse, but what about memory? > > How to protect from an application that mlockall(MCL_FUTURE) and > > has a memory leak? > > If you fail to solve this problem, then we end up back where we are > right now: patching kernels or running untrusted audio applications as > root. This solution is much worse than the problem you were trying to > solve. I have an idea! rt_monitor is running mlockall and I avoided * dynamic memory allocation * system calls - If I split the function into server and monitor (two threads) it would be even better. So rt_monitor itself should never get stuck requesting more memory, nor get stuck in a system call getting stuck on another process requesting more memory. But it could monitor the RT processes memory usage and kill those crossing the line. Will try it tonight... /RogerL -- Roger Larsson Skellefteå Sweden
