Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
On Thu, Aug 29, 2002 at 09:12:07PM +0200, Stefan Westerfeld wrote: I am very interested in that. In all the discussions we had about the RT issue in aRts, things usually came to the point: basically, it is a kernel bug, that as soon as you use RT prio, your system becomes unstable. Especially if you combine that with dynamically loaded modules, which even might be third party, both approaches to work around the problem break. This is no kernel BUG, this is POSIX. People actually rely on POSIX in this regard and the kernel has to follow. If you work around Unix protection mechanisms by loading unknown code into the virtual memory image of your privileged application YOU are opening a security hole and cannot expect the kernel to protect you or your user. For the kernel you and the malicous code you just loaded as you module is EXACTLY THE SAME unless you give it a seperate process. So please stop pointing out kernel bugs, where the kernel is behaving as required by POSIX and people who use the POSIX features. Regards Ingo Oeser -- Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
[linux-audio-dev] a jack question
given kernel capability patch applied, does jackd give real-time capability to existing running process (normal user) that decide to become a jack client? liulk
Re: [linux-audio-dev] a jack question
given kernel capability patch applied, does jackd give real-time capability to existing running process (normal user) that decide to become a jack client? yes, it gives the needed capabilities to the audio thread that gets created for each new client (not the whole application, of course). You have to use jackstart (suid root) to start jackd instead of starting jackd directly. -- Fernando
[linux-audio-dev] Notation program.
Hi folks, is there a music notation program for linux that really does the job well - you play your MIDI keyboard and a reasonable approximation to a score appears on your screen? I've tried rosegarden but the editing facilities are a bit primitive and it doesn't really print out. not WYSIWYG anyway. If not I might have a hack at writing one.. Charles. Prof. Charles J. Read, Dept. of Maths, University of Leeds, Leeds LS2 9JT, UK. work phone 0113 233-5179 email [EMAIL PROTECTED] webpage http://maths.leeds.ac.uk/~read
Re: [linux-audio-dev] Notation program.
Last time I did a score in CMN. If I were to do what you want to do I would try Rosegarden or Muse to create a raw midi file. Then I would export that then import it into lilypond. I would then edit it by hand. I actually like this idea better than working with Finale. Finale was always screwing things up. Then I could never remember what all those stupid buttons do. Jeremiah On Fri, Aug 30, 2002 at 07:41:21PM +0100, Charles Read wrote: Hi folks, is there a music notation program for linux that really does the job well - you play your MIDI keyboard and a reasonable approximation to a score appears on your screen? I've tried rosegarden but the editing facilities are a bit primitive and it doesn't really print out. not WYSIWYG anyway. If not I might have a hack at writing one.. Charles. Prof. Charles J. Read, Dept. of Maths, University of Leeds, Leeds LS2 9JT, UK. work phone 0113 233-5179 email [EMAIL PROTECTED] webpage http://maths.leeds.ac.uk/~read
Re: [linux-audio-dev] Notation program.
On Friday 30 August 2002 19:41, Charles Read wrote: Hi folks, is there a music notation program for linux that really does the job well - you play your MIDI keyboard and a reasonable approximation to a score appears on your screen? I've tried rosegarden but the editing facilities are a bit primitive and it doesn't really print out. not WYSIWYG anyway. If not I might have a hack at writing one.. Well why not just offer to help us (Rosegarden) out instead of starting yourself from scratch? There are many many music projects that have been started with few enough ever coming to fruition without potentially wasting more effort. We're still in development and open to ideas and we'd be most interested to hear your specific comments. You're using Rosegarden-4 I take it? Have you played about with quantizing of your recorded MIDI a little and see how that affects the score on the screen? Do you really think the notation layout is unattractive? It's true that our printing facilities are a bit limited at the moment but again if you want it sooner then please pitch in. There's a reason it's open-source you know? R [cc'ing rg-devel]
Re: [Rosegarden-devel] Re: [linux-audio-dev] Notation program.
Richard Bown [EMAIL PROTECTED] writes: It's true that our printing facilities are a bit limited at the moment I would say that if you want really good printing, you should probably accept a non-WYSIWYG approach and use Lilypond as your printing engine at least, even if you use an interactive editor such as Rosegarden-4 or Denemo to get the data into Lilypond format in the first place. We would like to do much better native printing from RG-4 than we do at the moment (not hard -- native printing is completely useless at the moment), but it'll never be as good as Lilypond. As for editing capabilities, it would always be useful to know what you're wanting to do and how the program could do a better job of helping you. How else will we improve it? And Rosegarden is not your only option: you should take a look at NoteEdit and Denemo as well, if sequencing is not of any interest to you. I think these are enough projects to make it far more worth your time contributing to one of them than starting your own, but obviously it's up to you. Notation is not particularly easy to do though. Chris
Re: [linux-audio-dev] Notation program.
One thing lacking on any platform is notation software with user adjustable pitch tables that supports midi tuning standard. I have a lot of experience working with altered tunings and pitch tables studying balinese gamelan, my C/C++ skills still suck right now, but I sent my girlfriend away for the weekend just so I can work my way through the rest of oreilly's practical c. On Fri, 2002-08-30 at 15:06, Richard Bown wrote: On Friday 30 August 2002 19:41, Charles Read wrote: Hi folks, is there a music notation program for linux that really does the job well - you play your MIDI keyboard and a reasonable approximation to a score appears on your screen? I've tried rosegarden but the editing facilities are a bit primitive and it doesn't really print out. not WYSIWYG anyway. If not I might have a hack at writing one.. Well why not just offer to help us (Rosegarden) out instead of starting yourself from scratch? There are many many music projects that have been started with few enough ever coming to fruition without potentially wasting more effort. We're still in development and open to ideas and we'd be most interested to hear your specific comments. You're using Rosegarden-4 I take it? Have you played about with quantizing of your recorded MIDI a little and see how that affects the score on the screen? Do you really think the notation layout is unattractive? It's true that our printing facilities are a bit limited at the moment but again if you want it sooner then please pitch in. There's a reason it's open-source you know? R [cc'ing rg-devel] -- http://www.brianredfern.com ;-)
RE: [linux-audio-dev] Notation program.
To me it seems like you do not have to have an application aware of pitches (unless you feel uncomfortable using conventional notation for custom-assigned pitches -- i.e. c is c, c# is a bit flat, d is more like c# etc. so you'd need 2 conventional octaves for one 24-pitch microtonal octave). Many contemporary composers do this -- alter existing notation so that it can serve their purpose. Assuming from your e-mail is that you may be comfortable with modern notation, so I'd suggest simply using external midi module where you'd edit the sound patches to have this kind of detuning, or even better a sampler of some sorts. Then, you'd simply pass a conventional midi file to hear gamelan-like tunings that are produced by the external midi module (or any other tunings for that matter). That being said, I do agree with you that this would be a neat feature within a sequencer without continuously employing fixed pitch-bend wheel values. Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God One thing lacking on any platform is notation software with user adjustable pitch tables that supports midi tuning standard. I have a lot of experience working with altered tunings and pitch tables studying balinese gamelan, my C/C++ skills still suck right now, but I sent my girlfriend away for the weekend just so I can work my way through the rest of oreilly's practical c.
[linux-audio-dev] Proposal of LADSPA port hint DATA_PRESENT
I suggested this a while ago and the more i thought about it the more i thought it was a good idea, hopefully others can set me straight:) /* Hint LADSPA_HINT_DATA_PRESENT indicates that the data item should be used to signal that the audio stream has stopped. It must be used in conjunction with LADSPA_HINT_TOGGLED. The host signals the plugin that the audio input stream has stopped. The plugin subsequently signals the host that the audio output stream has stopped. The first step requires an input port while the second requires an output port. The plugin should only look for changes in the input port state while the host may use the value of the output port state. A plugin should expect to be deactivated immediately after signalling the host that output has stopped. */ Motivation: there are 3 cases where this hint is useful, 2 of which I think fit the LADSPA criterion of falling into the intersection of all audio applications. First, discontinuing polyphonous voices. Under LADSPA, polyphony is implemented by allocating 1 instance of a plugin per note/voice. When the voice is stopped there is a decay period of time which is more inherent to the plugin then it is the host. To allow a host to deallocate a voice safely and efficiently, the DATA_PRESENT mechanism has the host signal the plugin that the activitity is over and the pluging subsequently signals the host that it has concluded its audio activity. At this point the host can deallocate the plugin instance without risking losing any worthwile information. #1 In Intersection? Hosts use a variety of methods to manage multi-voice activity. While the host can keep track of all the input passed to a plugin, it is more properly the domain of a plugin to know when it is finished with a job. The privileged position of the plugin with regard to knowing state information at wrapup carries across host/plugin arrangements. Even if the plugin has no decay, that is still a piece of information that it knows which the host does not. #2 Finite Impulse Response Filters. many plugins used as effects on an audio signal will generate output for some finite period after input has stopped. Examples include echoes and reverbs. once again the plugin has knowledge about when it has completed producing output whereas the host can only conjecture or defer the decision to the user. Third, non-realtime effects which change file length. This does not warrant being put in LADSPA but is a freebie fro mthe adoption of DATA_PRESENT. plugins which are applied to entire soundfiles can result in an output soundfile of a different length. as an example; a granular filter which changes tempo without effecting pitch. the host could conveniently know the range of the output file. the plugin could defer producing output until it has run enough data to fill some internal needs. Compatibility: If both the host plugin are either aware or unaware of the DATA_PRESENT mechanism their is no compatibility issue. If the host is aware but the plugin doesn't use it there's no compatibility issue, the host will see there is no DATA_PRESENT port and run the plugin longer. If the plugin has the feature but the host does not there is a consideration: the host will not know how to set the data input port signalling data present. Therefore the plugin must only pay attention to changes in the state of the DATA_PRESENT input port and not the actual state. Practically this should not present a problem because most hosts expose all plugin parameters to the user who can toggle the control on and leave it there. The plugin can defer the beggining of ouput until later than it first recieves input and tell the host it is doing so with the mechanism. It could do the same without the mecchanism so this causes no compatibility issues as long as the plugin fills the pre-output buffers with zeroes. Also the plugin must not abuse the mechanism to break up its output into discontinuous patches, This would cause large compatibility problems. The output image must be continuous in time. This is ensured by the statement plugin should expect deactivation on sending the false signal. Generally, if you think of LADSPA plugins as two dimensional fxns from a domain limited in height to -1 to 1 and with width being time, then they map to some output range with the same vertical limitation but the only time limitation being that the start of output = the start of input. The DATA_PRESENT mechanism allows the host to discover the limitations of the output time range, which are different for each continuous run of the plugin . My argument is that the range of the output in time is useful information to the host in every audio application and that it is something the plugin has to communicate to the host because the host can not be expected to determine it on its own. please reply. --jacob robbins---
Re: [linux-audio-dev] Question regarding network coding
On Fri, Aug 30, 2002 at 11:49:32PM -0400, Ivica Bukvic wrote:
Hi all,
I am already aware of some networking stuff, but am not sure as to how
to make client aware that the server has finished sending the struct
(since some values, like strings can be of different lengths, I can not
simply just specify a fixed size of the information to be received).
you should probably tell the client how much to expect. if you are
using tcp you have to do your own framing since it's a streaming
protocol. (in constrast, udp is a datagram based protocol).
msg: | preamble | length | type ||
etc. you can use the preamble to give the receiver a reasonable shot
at resynching to the stream if something goes wrong.
Furthermore, the only time I worked with network stuff was with
streaming soundfiles, it seems that the process would be stuck in a loop
until the transfer was complete. So my question is how do I make this
networking process instantiate itself, but then let it run as a
side-routine? Do I need to create a separate thread (or thread(s) in the
case there are more clients) in order to have these networking processes
running?
the basic outline for a tcp server is
ssock = socket...
bind(ssock,...)
listen(ssock, ...)
while (1) {
clientsock = accept(ssock)
fork...
}
where fork is either a fork proper, or pthread_create, pass the
thread the clientsock and you should be ready to go.
here's some code and explanations:
http://world.std.com/~jimf/papers/sockets/sockets.html
you can also get the software from comer's tcp/ip books
http://www.cs.purdue.edu/homes/dec/netbooks.html
this is from memory ... someone correct me if i'm wrong.
rob
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: [EMAIL PROTECTED]
