its been a productive evening/night. or has it?
i hacked up a small test that runs Qt as a host, and loads a shared
object that uses GTK+ as its GUI. the host loads the shared object,
and runs its GUI, in addition to its own. cool, eh?
well, not so fast. i am now wondering what in the hell all
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop
what would all this mean for LADSPA?
1) there would need to be a way to associate plugins+GUIs since we
probably don't want them in the same object.
- could be done using LRDF or a dir search path combined with the
plugin ID.
2) the GUI would have to declare which toolkit it was
Paul Davis wrote:
what a night (paul simon on the famous AG concert in central park)
6) [ only if we really wanted hosts to have a real handle on the
plugin GUI window ] the library would need to contain a way to
pass in an X Window, and wrap it up as a native drawing area
for each
These updates makes it possible to use windows vst plugins in
linux applications getting very descent realtime performance.
I have successfully ran vst plugins in ardour with 2.66 ms latency.
Sources:
http://www.notam02.no/arkiv/src/
Linux Vst Compatibility Page
http://80.61.20.184/vst/
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to jack even rt_monitor did not helped,
the machine keeped totally
I'd like to say: woohoo!
On Tue, Nov 18, 2003 at 02:23:05 -0500, Paul Davis wrote:
what would all this mean for LADSPA?
1) there would need to be a way to associate plugins+GUIs since we
probably don't want them in the same object.
- could be done using LRDF or a dir search path
6) [ only if we really wanted hosts to have a real handle on the
plugin GUI window ] the library would need to contain a way to
pass in an X Window, and wrap it up as a native drawing area
for each toolkit. i would prefer not to do this for now, if ever.
What about reparenting the
I'd like to say: woohoo!
i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.
What are the arguments against stuffing the UI code in the same .so file?
what
On Tue, Nov 18, 2003 at 09:22:13 -0500, Paul Davis wrote:
I'd like to say: woohoo!
i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.
In that case its
On Tuesday 18 November 2003 02:14, Paul Davis wrote:
to put in bluntly, it appears that i have been totally and utterly
full of crap, and have unnecessarily delayed the advent of decent
plugin GUIs on linux by a year or more.
So, book yourself a guilt trip, and when you return, life will go
the following is tiny example to show that its possible to use XEMBED
or just native X Window IDs to create host-managed plugin GUIs. GTK+2
and Qt3 both support XEMBED; GTK+2 supports use of native X Window ids
when creating new top level windows, i am not sure about Qt (does
anybody here know how
For what it's worth, this can also be done with FLTK.
Maarten
For what it's worth, this can also be done with FLTK.
XEMBED style, or foreign window style ? i've already learnt how to
do it with Qt ...
On Tuesday 18 November 2003 13.28, Stefan Nitschke wrote:
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to
XEMBED style, or foreign window style ? i've already learnt how to
do it with Qt ...
I don't remember.. I did it once. I think it was foreign window style.
Anyway, I'll give it a try tomorrow.
Maarten
Tuesday 18 November 2003 15.22 skrev Paul Davis:
I'd like to say: woohoo!
i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.
As others have also
i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.
As others have also noted, adress isolation is god sent. Whatever you do,
chiming in, address
On Mon, 2003-11-17 at 19:59, Jack O'Quin wrote:
To summarize, my proposal is:
sysctl -w kernel/realtime=0 # disable realtime privileges
sysctl -w kernel/realtime=1 # enable realtime privileges
# for `root' group
sysctl
On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote:
i offer this as a proof of concept. i believe that our problems with
GUIs for plugins are pretty much over, modulo defining some standards
as per another recent from me.
Paul,
I freely confess that I do not know how X works. Can you
On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote:
i offer this as a proof of concept. i believe that our problems with
GUIs for plugins are pretty much over, modulo defining some standards
as per another recent from me.
Paul,
I freely confess that I do not know how X works. Can you
One important thing to remember - if you like to get broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
I don't (personally) want or need at this
On Tue, Nov 18, 2003 at 02:50:37 -0500, Paul Davis wrote:
if we avoid the goal of having the host have some control over the
plugin GUI window, then this isn't necessary, and the design i
implemented last night will work without any special support from X or
toolkits. it does require a small
On Mon, 2003-11-17 at 04:07, Paul Davis wrote:
Thanks for pointing out the errors in code.
1) the null cycle callback is wrong. it will generate random noise, and
should instead generate silence.
OK, fixed...
2) the buffer size callback is wrong. you have to stop the hardware,
On Mon, 2003-11-17 at 04:06, Jack O'Quin wrote:
One helpful thing you could do would be testing it on a system with a
real OSS driver.
I'll test it in near future.
Sample Rates = 48000.00, 44100.00, 32000.00, 24000.00, 22050.00, 16000.00,
11025.00, 8000.00,
Native Sample Formats =
Found some good reading material on real time programming and now have a
couple more questions if anyone can share:
- what are the pros and cons for a sequencer engine of using pthreads in one
address space vs seperate processes spawned by one application? Anyone know
what the various linux real
Now the oss driver for jack 0.90 starts to shape up. This could be
considered as alpha version.
Changes:
- Conditionally compiled two thread implementation for NPTL (possibly
also works with LinuxThreads, untested)
- Fixed a load of bugs
This version has been tested with CMI8738, ENS1371
- Conditionally compiled two thread implementation for NPTL (possibly
also works with LinuxThreads, untested)
would you mind explaining why you are using 2 threads? it seems
pointless, but perhaps i'm missing something...
On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
Wouldn't
1. A short summary of changes
Ecasound's emacs mode, ecasound.el, has been updated to
version 0.8.3. Due to severe bugs found in the native Python
ECI implementation, the C implementation has been again set as
the default. Minor interoperability problems with older JACK
releases and Ecasound
On Tue, 2003-11-18 at 23:59, Paul Davis wrote:
- Conditionally compiled two thread implementation for NPTL (possibly
also works with LinuxThreads, untested)
would you mind explaining why you are using 2 threads? it seems
pointless, but perhaps i'm missing something...
One is for input
Melanie [EMAIL PROTECTED] writes:
Wouldn't it, just maybe, be acceptable to the kernel people if
capabilities could be turned on by some parameter on the kernel
command line (e.g. capabilities=on)?
We could ask. But, I suspect they will feel that they have adequately
solved this problem in
On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with complete confidence that even if you do not use the
Melanie [EMAIL PROTECTED] writes:
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with
On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote:
ping is answered = IRQs live.
Could you please try this.
Start rt_monitor in a text console CTRL-ALT-F1
Start your client, return to console - what does rt_monitor print?
(It could be the memory leak and mlockall(FUTURE) problem,
Disclaimer: I have not read the entire GUI thread so please don't flame
me (but correct me)
if I say nonsense.
Having written a few engines (midi player, audio player) and the
corresponding GUIs of
the upcoming Lionstracs Mediastation keyboard, we have faced the same
problem old problem:
we
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
On Mon, Nov 17, 2003 at 09:59:11PM -0600, Jack O'Quin wrote:
martin rumori [EMAIL PROTECTED] writes:
senseless) as default. granting realtime privileges to everybody is
exactly what we don't want... and it's likely to do that by accident
I agree that 0 should be the default. It exists on
40 matches
Mail list logo
