On 06-01-12 11:21, Pedro Lopez-Cabanillas wrote: Thanks, I was thinking that maybe it would be nicer to connect from my program to Hydrogen. Then I don't have to restart Hydrogen everytime my program has ended. Dave

On 06-01-12 12:06, Dan Muresan wrote: I my case I want to have only a drum synth playing and controlling it with midi messages. I think that doing it with Jack would give me extra delay. Dave

Not the communication, but I think Hydrogen over jack has more delay then directly, but I don't know this for sure. Also jack causes other , not jack programs like audio plugins for browser, to hang/stop. I think that in the case I also like to use my normal desktop applications and a sequencer I jump to alsa. Why is jack / or an other audio layer not completely integrated like in windows and mac os, so that you don't have to start al the seperate applications? Dave On 06-01-12 12:33, Dan Muresan wrote:

On 06-01-12 13:22, Paul Davis wrote: Ok, maybe that's true. But the use is in the basic situations more simple I think. don't get me wrong. I am a linux fan anyway ;) Ok, that's true. Sometimes I get very frustrated to start all these applications seperatly. Also lash seems to be dead(according to it's creator). And I don't think Jack sessions is going to be adopted by al these programs.

On 06-01-12 13:40, Dave Phillips wrote: I have already done those things. But it is not completely satisfying. I wrote some stuff to startup as a project. So lets say I want to compose a song called "song" I start a couple of seuencer programs with jack and save it under the same name like song.muse , song.hsong etc.. But during the project you also like to add instruments etc. then it is a little more complicated and less transaparent.

On January 6, 2012 1:32:36 PM Dave Stikkolorum wrote: LADISH has stepped in as a emulating replacement for LASH. By now it may be fully functional. Nedko, is it working yet? Tim.

Am Fri, 6 Jan 2012 23:05:09 +0100 schrieb thijs van severen <thijsvanseveren(a)gmail.com>om>: and also full jack session support ;) greetings wolke

On Friday 06 January 2012, Dan Muresan wrote: The decision about using one MIDI API or another, one GUI framework or another, one programming language or another, in my case depends only on what I find the best suitable tools for a task. I can't care less about the latest fashion, or the most popular thing, because in that case I would not be writing Linux applications. You know: Linux usage is absolutely marginal, also among musicians and audio professionals. I find Jack MIDI unsuitable for my use cases, so I usually don't use it. Regards, Pedro

Well I must say, as a musician the things you can do with linux amazed me. To reach a larger public things have to be more fancy / more use friendly. So you would use it as an user without programming background. On 07-01-12 11:55, Pedro Lopez-Cabanillas wrote:

If you're writing for yourself only, no one can argue with that; but I was talking about public-facing apps, in which case standardizing on a single MIDI protocol helps users (and the ecosystem in general). I've always thought that Jack MIDI is easier to program and provides better jitter guarantees, but you may see things differently. It would be interesting to know which use cases you are encountering? -- Dan

So I tried jak midi , that's also an option. Still have to figure out the process-callback in the context of my program. What my program does is the following: I have a simple usb drum kit, that is actually just working a gamepad and recognized as /dev/input/js1 I can use the jostick examples from linux + jack midi to make Hydrogen play a sound on action on one of the drum-pads. So I think I can just make a buffer with one midinote en let the callback empty that? Dave On 08-01-12 00:31, Paul Davis wrote:

On Sun, Jan 8, 2012 at 6:14 AM, Pedro Lopez-Cabanillas <pedro.lopez.cabanillas(a)gmail.com> wrote: this is bullshit, pure and simple. there is no MIDI API (on Linux or anywhere else, not considering plugin APIs) that ensures the delivery of MIDI in the same thread as audio processing. this means that if you are doing synthesis based on MIDI data, which after all is the original purpose that MIDI was intended for, and you're not using JACK then you face issues of either latency or jitter (or both). JACK MIDI aims to solve those problems at the same time as offering developers (and users) the same abstractions and application design and interface as they would use for audio. Given that MIDI's primary purpose has been to drive and control audio synthesis, that seems entirely appropriate. Now, should you want to use MIDI for some entirely different purpose - for example, the subsets/extensions of MIDI such as show control or machine control, then its certainly true that JACK MIDI isn't really the idea API for that. This would also apply if you wanted to use MIDI to control automated equipment in your house. Its also the case that if you are sending pre-existing MIDI data, then JACK MIDI is somewhat more cumbersome than the type of API like ALSA's, which allows you queue up a huge chunk of MIDI data and have its delivery taken care of for you. Somebody could easily provide a wrapper for this around JACK MIDI, but it hasn't happened, I suspect because most things that send MIDI are not actually "MIDI file players" and the "file player" type of application is already well addressed with ALSA-based utilities. For sequencer applications like Ardour, Muse, QTractor, Rosegarden and so on, the ALSA API actually creates an entire additional layer ot complication if you want precise synchronization with audio synthesis. So, I'm not precisely sure what other use cases you see for MIDI besides one that intimately links MIDI with audio data in real time, but no matter what they are, this such an overwhelmingly common and dominant use case that JACK MIDI's model of things appears to me entirely appropriate and very far from hype and propaganda. Yes, its true that it would have been better not to create a new API. But if you talk to the people involved in the original design of the ALSA sequencer, they acknowledge that for the last 6-7 years at least, it could have been in user space and probably should have been. Nobody is willing to put the time in to change that, and so ...

Hello Ralf! I don't exactly get the finer points of your argument. You may have gone a little astray in your passion. But why should Linux not have fancy GUIs? I can't use a lot of them right now, but I could do more, if I only got my arse of the ground and persevered in my efforts to set up GNOME and Orca. Fancy is nice. I get "fancy" in other ways and I do like it. Certainly it's nice when apps respect some global settings of yours,but especially in our field, sometimes it's just not on. We are - at the heart - a lot about creativity and user interfaces do shape our workflows and methods. If you want something, that lets you absolutely have your way, then I suppose you'll be back with Csound and high-level audio programming libraries. Granted there are applications, that are fancy and flexible, but it's a hell of a lot to program and it can't apply to everything. and then of course, we always have ideas, when we start something. We - as musicians - have ideas about the kind of music we make and the programmers have ideas about the interfaces they make. In a way that too is a form of art. As a final remark: I do like applications, that adhere to standards and if possible respect global settings. Because in a case like mine - and others -, that too might mean, taht such settings are paramount to making a software accessible/usable. But Linux - as any other OS - is meant to be used and thus has to advertise and move with the times, not only in background technology. And that is as it should be. Warm regards Julien ---------------------------------------- http://juliencoder.de/nama/music.html

The biggest problem is the quality. With pixmap-based themes it may be achieved only when special pixmap areas are specified for borders, which are not scaled in certain dimentions. The only gui, which is known to support this, is kde plasma. As for gtk — it may require newer engine (if old good pixmap or pixbuf engine doesn't allow that). In previous month i spent time, creating theme for qtcurve — "Hardcurve". Though published on kde-look (which is subportal of www.opendesktop.org), it is good for gtk as well, since qtcurve is cross-toolkit. Very sad, that ardour doesn't allow at least to customize, wether to use or not included theme (like rosegarden does).

Am 17.05.2013 08:58, schrieb Ralf Mardorf: I'm sign for this UI design. :-) The easiest way to get around this, is "Just Dont Use It" . If you feel the need to use it, and you don' t like the provided themes it is easy to wrote your own. Themes in guitarix are based on rc files, you just need to wrote one, If you would use your own desctop theme with guitarix, a empty rc file is all you need, install it in the guitarix rc dir and you can use it. guitarix will find and it there and provide the menu entry to select it. required is just the naming scheme "gxX_name.rc" were X is a number. However, I understand that this isn't want you wont to hear, from what I understand is, you just wont to bashing . . . Because, why you ignore the usual way to contact project maintainers and let them know about your issue? Why you never react on one of my announcements here and let me know what you think? Instead of that, you hide your bashing behind a thread tittle which have nothing to do with the subject of the mail? So, my conclusion is, you are not interested in a solution for this. But Ui design is art, and art will never match anybody’s taste.

Am 17.05.2013 13:40, schrieb Ralf Mardorf: Regardless from if I like your responses or not, as a project maintainer, I didn't like to see bashing like you do (a way to often for my taste, indeed) in open mailing lists. We provide several contact possibility's for users to solve such issues, and we are willing to solve them, and for the most of them there is the solution already included but not documented. All that is regardless from, if I like you or not. And in the same way that makes you feel yourself free to provide your 'bashing', or lets call it "your meaning" against "my" project, in the same way I fell free to say you that I didn't like the way you do it. ;-) And now, the devil dance in cycles. :-D