On Monday 01 March 2004 00:43, Dave Robillard wrote: I don't now if hydrogen does this. For now lindrum does not do it (it's italic in the feature list ;). But the idea is: the eq is implemented using a LADSPA plugin, this concept has proven to work for me. So i want to do alike with the pitch - use a ladspa plugin. If i have not overseen some pitfalls here, this is the way i will implement it. Aah, the toolkit! I know the discussion according Qt and other toolkits and i don't want to start another debate here ;) But I have to admit: I'm a C++ programmer and i like - no - i love Qt. I know there are people who doesn't and that's good. A followed the gui discussion on the list and i am quite happy that a toolkit independent solution is favoured. According lindrum: The engine can (in theory) be run completely independent from the gui (and then controlled by MIDI). For now there simply is no executable which starts the engine only. This will be available in a future release. PE -- "Without music, life would _O_/ \_O_/ +----------------------+ be a mistake - I would / )) [] | Peter Eschler | only believe in a god who \\ // | peschler(a)t-online.de | knew how to dance." (Nietzsche) // \\ +----------------------+

On Monday 01 March 2004 01:49, CK wrote: No it does not have to be 3.3. A realized this flaw when packaging the relase and i had no environment using qt<3.3 availbale. I will try to build an .ui file on a 3.1 system and get it to work. PE -- "Without music, life would _O_/ \_O_/ +----------------------+ be a mistake - I would / )) [] | Peter Eschler | only believe in a god who \\ // | peschler(a)t-online.de | knew how to dance." (Nietzsche) // \\ +----------------------+

On Monday 01 March 2004 02:08, Dave Robillard wrote: Ok, ok, you mean signals/slots and moc stuff? No C++, admitted ;) Please keep em! As long as we don't get physical ;) Yeah, a screenie means at least it did compile ;) I know it look's ugly with another theme. That's pointed out the webpage. Give me some time to breath, i will work on this.. Anyway, do you have it up and running? If so, forgot to mention: Keys 1-9 and 0 trigger the channels 1-10 Keys 'l' and 's' open dialogs for loading/saving patches PE -- "Without music, life would _O_/ \_O_/ +----------------------+ be a mistake - I would / )) [] | Peter Eschler | only believe in a god who \\ // | peschler(a)t-online.de | knew how to dance." (Nietzsche) // \\ +----------------------+

On Mon, 1 Mar 2004, Frank Barknecht wrote: I don't quite understand this attitude. Testing hydrogen would involve apt-get install hydrogen, start it and listen to the demo song. Probably soon the same will be true for lindrum. Of course it would have been better if the two developers would have built a team and improved one drum sequencer instead of duplicating functionality. Lack of collaboration is one of the weaknesses of the free software development (peculiarly enough it is considered one of its strenghts), especially with audio software. Just count the amount of software synths, audio languages, editors, and then look at their quality and usability. Guenter

On Mon, 2004-03-01 at 07:07, guenter geiger wrote: A weakness compared to what? Proprietary software is /definitely/ not immune to this problem (in fact, I'd say it's far worse - there's no collaboration whatsoever). Is is really a weakness of free software if non-free software has the same problem? I don't hear people complaining about Steinberg and Emagic 'duplicating effort'. Don't get me wrong, I do think duplication of effort is best avoided if possible, but I don't think it's a "weakness of free software". -Dave

On Mon, 1 Mar 2004 10:24:26 -0800, Tim Hockin wrote The (most common) motivation for writing free software is for fun and interest, not thinking about the bigger picture from a users point of view, ie you dont really care how many other apps do the same thing as yours - as a developer you just want to write the app in your way and put your name on it :) Also large teams are not really the answer - often one or two people work much more effeciently due to communication overhead. I can't remember the stats, but you have to get to quite a large size before you get the advantage back (and have lots of red tape and boring procedures to follow) The answer is to have common stuff like JACK and LADSPA - this seems to work really well, and share out the bits that appeal to different developers. dave ................................. www.pawfal.org/nebogeo

On Mon, 2004-03-01 at 14:37, Tim Hockin wrote: Speaking of GMPI, what's the status there anyway? Coincidentally, my dream modular synth (and effects bay) could use a more advanced plugin format than LADSPA... Is there a GMPI progress page or something like that? -Dave

On Monday 01 March 2004 19:53, Dave Griffiths wrote: Seems i started a discussion here. Before i comment on my motivation for writing lindrum, i want to address the name issue. I knew of the Linndrum and i have to admire that i was somehow inspired by it. I removed one n and this suddenly fitted to Linux. Voila! What i didn't know is that the company is still in business. So in fact it might be necessary to find a new name. Surely i tried hydrogen.. and i like it. I thought about participating or contributing, but my "vision" was somehow different. So i decided to learn first, looked in JACK and LADSPA and wrote me a wrapper just to get known to the APIs. It was fun and it worked. On the the other hand i do a lot of gui programming. The dials in lindrum e.g. where done long ago absolutely independent of lindrum. Someday then - when i did some music on that other system, once again sitting in front of a my favorite drum machine - i asked myself if it would be possible to implement this machine using all this common stuff like JACK, LADSPA ... I just tried "for fun". Someone mentioned that. And yes: I looked into hydrogen code. To learn. I looked into lot of little projects code. Dead projects. To learn. And IMHO they're not useless. Maybe my project will be dead at the end of the year. But then i made my experience and still can join hydrogen or other projects. CYa PE -- "Without music, life would _O_/ \_O_/ +----------------------+ be a mistake - I would / )) [] | Peter Eschler | only believe in a god who \\ // | peschler(a)t-online.de | knew how to dance." (Nietzsche) // \\ +----------------------+

Hi, I agree with you and I don't think that you, or anybody else spend their times badly if they start new projects, on the contrary, the more the merrier! :) The main requirement when you are about to create something is motivation. If you don't have that and start poking at something you will sooner or later run out of steam, unless you have an iron will. This might be the case if someone tells you which project project to start on, it'll work for a while, but then it's quite probable that you would lose interest. I've always argued that if you zoom out and look at Open Source development from a distance it is evolutionary. Apps appear and die away all the time, only the ones with good life force will continue to strive. This life force can be made of many things. For example: if the app interests a lot of people and they have found common ground in developing it together, or the app has a very stubborn lone developer that just won't give up. Both these kinds of apps will continue to live and possibly grow into something huge. Whereas some apps are started out of a need/interest but didn't attract any immediate attention and the developer lost interest, they will sooner or later die away. There is nothing wrong with that. This does also imply that open source development on a large scale is a rather slow process (not that any software development is fast), and we that are now participating in Linux Audio are working in (my opinion anyway) a very young development arena so diversity (or lack of direction if you will) is only natural at this instance in time. The more specialized projects that attract lots of developers _will_ come (there already exist a good bunch). Of course the analogy isn't perfect, (or we would have to wait millions of years :-D) with clever management we can increase the speed and skip a few iterations. Which is how I for instance would describe the success of Jack. My point is though that you can't force people into doing what they do not have any immediate interest in, their time is better spent making a larger base of developers overall, who knows, perhaps it's _their_ app that got it _right_. Not the possible predecessor. And even if their app fail, they would have learned something that they can later make use of, and the code would still be available as evidence that there once was a project in that vein. Even if the code in itself could not be reused it might serve as inspiration for others to start something. Sorry for being long winding, Robert

On mån, 2004-03-01 at 19:53, Dave Griffiths wrote: I wholeheartely agree! I write my stuff for (uhmm?) Me!! I do not expect anybody to have have any similar goals, but the source is there just in case. I use my own product though, so I try to make the UI as easy to deal with as I can manage. (Otherwise I would be counterprodutive, no?) If I have missed some abondoned project, then so what? How can that take away my present joy of understanding what I am trying to accomplish? How can that take away the joy from that abandoned project that I might never have seen? And damned right yes, I stick my name on what I am doing. There is blood in it, don't you know? Large teams implies endless meetings and arrays of pointy haired bosses without insight. In midi music you can observe the following pipeline though: live performance/auto-composer arpeggiator/keyboardsplit(for whatever parameter) sequencer/tape/HD recording and timing postprocessing routing and mix So at least eight people should be able work (according to your measures) simultaniously on a full fledged fundamental midi system. Therefore we can assume that there are eight little useful programmers: ADD 8 Now we'd like some synths/samplers/vocoders as well to fill out the empty spaces. If I had costumers I'd like to promise them to have at least a choice of (say) 42 very different pitch-shaping machines (being deliberately vague here ...) Two persons on each "pitchshaper" (or just call it "synthesizer") times fourtytwo adds upto eightyfour useful programmers: ADD 84 Then we will just need a few guys to do postprocessnig, reverb beeing one of the hardest part with a few teams calculated to fail .. ADD 8 .. and of course also phasers/flangers/chorus/multple-delays and such and such I haven't heard of .. ADD 16 Did I mention distortion? No? ADD 4 I now believe I need something like 116 talented and musical programmers to pull this one off .. Which is not excactly a small company. I How many are we? A thousind? Oh shit, you are right, we need Jack and friends sorry for beeing longwinded // Jens M Andreasen

On Mon, Mar 01, 2004 at 02:24:55PM -0500, Dave Robillard wrote: with gAlan its already possible although the documentation is lacking badly. polyphony is also possible with gAlan now. but it still needs some refinement. i hope to get it there this month. (polyphonic sheets) the problem with gAlan is that i dont have a midi-keyboard handy and do it all on the screen thats why midi controller stuff is not so nicely implemented. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Tue, Mar 02, 2004 at 08:23:16AM -0500, Dave Robillard wrote: midi in is available since 0.2.10 or so. just use the midi in port from the lib when you are on 0.3.0 otherwise you will have to fiddle with evtgates to separate the channels. the building block is Misc/ALSA Midi In it also supports as many jack ports as you wish. and if you have the jack-midi patch available also jack midi. although only in and without an out client it does not make so much sense :) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Mon, Mar 01, 2004 at 02:24:55PM -0500, Dave Robillard wrote: I haven't been able to follow AMS closely for the last weeks, being fully occupied with other things, buit AFAIK the polyphony problems should have been solved. Most of the related code was completely rewritten recently by Mastthias, and the dependency of the voice asssignment on the built-in ENV has heen removed. If you still have problems, please let us know what they are. -- Fons

On Tue, 2004-03-02 at 05:54, Matthias Nagorni wrote: Very nice, I was thinking of attempting to implement hold pedal myself it was so missed. I'll try to create the situation I had again.. it was something to do with envelopes all before a mixer which went into PCM out IIRC. I think the envelope was false triggering.. -Dave

Alle 19:24, lunedì 1 marzo 2004, Tim Hockin ha scritto: This is a nice point to discuss which brought a group of us (for a similar reason) to start the OpenJay Development Krew regarding OpenSource Software for dj environment (see more at http://www.openjay.org/ojdk/ ). We choose to cooperate cause a bunch is better than one! I personally think that one problem is not to find people to develop with but to coordinate them. I saw few people as flexible as a project maintainer needs to be( and I'm sure not among them! ). All this people maintains great softwares although. But a reason for this issue is that a big project, as a SoftSynth, needs lot of time and lot of text stuff only to discuss.... Another problem is the incredible will of reinventing the wheel: I saw too much code to write the same thing more and more! The thing is: it is always easier writing shit by yourself instead to write code taking lot of time to understand API's and other code... I think that some duplicates are needed: OSS is not only the best but also a wide choise... However I agree that a reason for the failure could be the inconsistence between project managers needs (on time, on choise...on whatever) and contributors ones... -- J_Zar Gianluca Romanin ---------------- see you at OpenJay.Org

what evidence do you have of the "armys of programmers"? my impression is that most audio s/w companies are pretty small, including the "big" names, when it comes to actual software development staff. --p

Dave Robillard wrote: Hydrogen internally has note's pitch support (you can look at the xml song files..) but has no Midi or GUI support yet. It's only a matter of time, now I'm working on a complete redesign of the pattern editor, including a "piano-roll" editor for bass lines and chromatic instruments edit. Ciao -- Alessandro <Comix> Cominu http://hydrogen.sf.net e-mail: comix(a)despammed.com Icq: 116354077 Linux User # 203765 [...Codito Ergo Sum...]