From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Jul 5 20:00:57 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA00370 for ; Sun, 5 Jul 1998 20:00:57 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106193-23082>; Sun, 5 Jul 1998 20:00:51 +0200 From: Stefan Westerfeld Message-Id: <199807051800.UAA00364@space.twc.de> Subject: Mailinglist up and running To: ksynth@kde.org Date: Sun, 5 Jul 1998 20:00:28 +0200 (CEST) Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"zS0YLu_yzWC.A.VDG.T97n1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/1 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 5 Jul 1998 20:00:51 +0200 Status: RO Hi! A new age in ksynth development has begun ;) We have a mailinglist now. That means that we should be able to coordinate development and design better, keep users and developers informed. I hope this will ensure continued improvments from the alpha stage we are in right now to a usable and capable piece of software. If you are not already subscribed, you can join easily by sending a mail with the subject "subscribe your-email-address" to ksynth-request@kde.org. The mailing list address is ksynth@kde.org. Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Wed Jul 8 21:07:49 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id VAA05503 for ; Wed, 8 Jul 1998 21:07:48 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106089-19417>; Wed, 8 Jul 1998 21:07:47 +0200 Message-ID: <19980708210715.32954@space.twc.de> Date: Wed, 8 Jul 1998 21:07:15 +0200 From: Stefan Westerfeld To: ksynth@kde.org Subject: Impressions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"9Sa5WeWo3kL.A.2rH.CO8o1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/3 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Wed, 8 Jul 1998 21:07:47 +0200 Status: RO Hi! If now finally there is a list, and there are even people subscribed, I would be very interested to hear about your first impression of ksynth. Did you get it to compile, did you get it started, did it work, did you understand how it works? We should constantly discuss possible weaknesses or possible thoughts how the next steps in development could look like. If you like to do something and something else is missing (e.g. you would like to write a module for ksynth, but there is no documentation how to do that), please mention this as well. Open development has its benefits when many people can work on solutions together, so lets get started. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 14 23:53:25 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA17334 for ; Tue, 14 Jul 1998 23:53:24 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106310-261>; Tue, 14 Jul 1998 23:52:58 +0200 Message-ID: <19980714215626.47643@space.twc.de> Date: Tue, 14 Jul 1998 21:56:26 +0200 From: Stefan Westerfeld To: ksynth@kde.org Subject: CVS - opinions? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"qlrn6UWglOH.A.7_.5M9q1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/4 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 14 Jul 1998 23:52:58 +0200 Status: RO Hi! I think it would be a good thing to make the ksynth code (and the other related stuff like midibus) officially available vie CVS. Would you like such an option? Would you use it? Perhaps it's too early to ask such questions since there are not enough people subscribed in here - but that will change I hope ;) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Jul 17 10:24:07 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA23251 for ; Fri, 17 Jul 1998 10:24:06 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106111-245>; Fri, 17 Jul 1998 10:23:36 +0200 From: Stefan Westerfeld Message-Id: <199807161736.TAA21731@space.twc.de> Subject: test, please ignore To: ksynth@alpha.tat.physik.uni-tuebingen.de Date: Thu, 16 Jul 1998 19:36:58 +0200 (CEST) Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"kvyOUfZJao.A.wZ.Iowr1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/5 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 17 Jul 1998 10:23:36 +0200 Status: RO t e s t From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Jul 17 11:06:47 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA23348 for ; Fri, 17 Jul 1998 11:06:46 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106339-291>; Fri, 17 Jul 1998 11:07:00 +0200 From: Stefan Westerfeld Message-Id: <199807161728.TAA21609@space.twc.de> Subject: Re: KSynth.... (fwd) To: ksynth@space.twc.de Date: Thu, 16 Jul 1998 19:28:37 +0200 (CEST) Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"eXDUH7zg25B.A.YVC.0Qxr1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/6 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 17 Jul 1998 11:07:00 +0200 Status: RO Hi! Forwarded message: > ja,... also eingetragen bin ich jetzt wohl in der liste... aber ueber > netscape kann ich nix senden... > hab' jetzt mal einen versuch ueber 'pine' gestartet... mal schauen, ob das > klappt... [ unofficial translation: He can't post to the ksynth list from his linux box. ] I don't know why this happens, I had some trouble before, but now it seems to work fine. Anyone else can confirm this? If you really can't post to the list, you can write to ksynth@space.twc.de istead. If you are able email me, you should be able to reach the list that way as well. ;-) It's just a stupid alias. > soo... jetzt schildere ich dir nochmal schnell die compilier-probleme: > also an ksynth liegts nicht, da ich die gleichen probleme auch z.b. mit > ksnapshot, kdtpanel, etc. > hab'. installiert hab' ich kde-beta4.1 und qt-1.33... (developers-pack), > pfade sind eigentlich > auch alle gesetzt. > und wenn ich dann z.b. ksynth compilieren will, kommen dann ein haufen > solcher meldungen, > bis das compilieren mit nem fehler abbricht: [ unofficial translation: It is not possible for him to compile ksynth, neither other "3rd party" kde apps due to the following errors: ] > [....] > th.o autorouter.o execdlg.o main.o module.o execdlg.moc.o main.moc.o > portpropdlg.moc.o portpropdlg.o -lkfile -lkfm -lkdeui -lkdecore -lqt -lXext > -lX11 -lmico2.0.8 -ldl -Wl,--rpath -Wl,/opt/kde/lib -Wl,--rpath > -Wl,/usr/X11R6/lib > autorouter.o: In function `QArrayT type_info function': > autorouter.o(.gnu.linkonce.t.__tft7QArrayT1Zc+0x13): undefined reference to > `QGArray type_info function' > autorouter.o(.gnu.linkonce.t.__tft7QArrayT1Zc+0x18): undefined reference to > `QGArray type_info node' > execdlg.moc.o: In function `ExecDlg type_info function': > execdlg.moc.o(.text+0x1df): undefined reference to `QDialog type_info > function' > execdlg.moc.o(.rodata+0x4d4): undefined reference to `QDialog type_info node' > > main.moc.o: In function `ModuleView type_info function': > main.moc.o(.text+0x34f): undefined reference to `KTopLevelWidget type_info > function' > main.moc.o: In function `ModuleWidget type_info function': > main.moc.o(.text+0x3c7): undefined reference to `QTableView type_info > function' > main.moc.o(.rodata+0x788): undefined reference to `KTopLevelWidget type_info > node' > [...] > make[3]: *** [ksbuild] Error 1 > [...] The problem you have is due to the RTTI feature of newer gcc based compilers (e.g. egcs). You either have to - use it on anything you compile, including the qt libs, the kde libs and stuff or - don't use it at all (disable it with -fno-rtti) I would recomment you the later version first, since it's not likely that you have rtti included in your KDE/Qt stuff, if you installed it from existing binaries. Another solution is to grab the complete sources, Qt-1.33 and KDE 1.0 and install everything yourself, rtti is enabled with the new compilers by default. So you will have everything with rtti and it will work fine as well. Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Wed Jul 22 09:39:25 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id JAA01826 for ; Wed, 22 Jul 1998 09:39:20 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106097-2990>; Wed, 22 Jul 1998 09:39:30 +0200 Message-ID: <19980722093450.60661@space.twc.de> Date: Wed, 22 Jul 1998 09:34:50 +0200 From: Stefan Westerfeld To: kde-multimedia@kde.org Cc: ksynth@kde.org Subject: KSynth/Cantor CVS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"KsAMWwzCssJ.A.tw.ycZt1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/7 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Wed, 22 Jul 1998 09:39:30 +0200 Status: RO Hi! Ok, I think we will put those apps into CVS soon now. My suggestion for a name would be kmusic. If anybody has got a smarter, nicer or better name, tell us. ;-) I would like to start checking in my sources this weekend, so hurry up with naming issues. The midibus development and standarization should also take place in the new kmusic CVS module, I intend to put it into the main KDE tree as soon as a) stable&usable and b) KDE requires CORBA. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From kde-multimedia-request@alpha.tat.physik.uni-tuebingen.de Wed Jul 22 10:30:07 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA01911 for ; Wed, 22 Jul 1998 10:30:06 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106097-2990>; Wed, 22 Jul 1998 10:30:29 +0200 Message-ID: <19980722093450.60661@space.twc.de> Date: Wed, 22 Jul 1998 09:34:50 +0200 From: Stefan Westerfeld To: kde-multimedia@kde.org Cc: ksynth@kde.org Subject: KSynth/Cantor CVS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;kde-multimedia@kde.org Resent-Message-ID: <"k0DhQOCUyTD.A.qVB.lMat1"@alpha> Resent-From: kde-multimedia@alpha.tat.physik.uni-tuebingen.de Reply-To: kde-multimedia@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/67 X-Loop: kde-multimedia@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: kde-multimedia-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Wed, 22 Jul 1998 10:30:29 +0200 Status: RO Hi! Ok, I think we will put those apps into CVS soon now. My suggestion for a name would be kmusic. If anybody has got a smarter, nicer or better name, tell us. ;-) I would like to start checking in my sources this weekend, so hurry up with naming issues. The midibus development and standarization should also take place in the new kmusic CVS module, I intend to put it into the main KDE tree as soon as a) stable&usable and b) KDE requires CORBA. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Wed Jul 22 11:24:06 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA02014 for ; Wed, 22 Jul 1998 11:23:58 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106905-2990>; Wed, 22 Jul 1998 11:24:36 +0200 Sender: pjl@bath.ac.uk Message-ID: <35B59EB2.69D8@bath.ac.uk> Date: Wed, 22 Jul 1998 09:11:30 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth/Cantor CVS References: <19980722093450.60661@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"Nb6-jwiB1KL.A.MIC.U_at1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/8 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Wed, 22 Jul 1998 11:24:36 +0200 Status: RO Stefan Westerfeld wrote: > > Hi! > > Ok, I think we will put those apps into CVS soon now. My suggestion for > a name would be kmusic. If anybody has got a smarter, nicer or better > name, tell us. ;-) kmusic sounds ;-) good to me. What about kmid, it should be near by since I use some of it's classes ? > I would like to start checking in my sources this weekend, so hurry > up with naming issues. I guess I should make cantor into Kantor for KDE ? I am new to CVS so I may need some assistance ( any URLs I should look at ?) > The midibus development and standarization should also take place in > the new kmusic CVS module, I intend to put it into the main KDE tree > as soon as a) stable&usable and b) KDE requires CORBA. Cantor will probably be usable quite soon, but stablity may take a little while longer :-) cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Jul 26 16:50:01 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id QAA11561 for ; Sun, 26 Jul 1998 16:50:00 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106205-7554>; Sun, 26 Jul 1998 16:50:49 +0200 From: Stefan Westerfeld Message-Id: <199807261449.QAA11555@space.twc.de> Subject: Re: KSynth feedback To: kouhia@nic.funet.fi (Juhana K Kouhia) Date: Sun, 26 Jul 1998 16:49:27 +0200 (CEST) Cc: ksynth@kde.org In-Reply-To: <19980723131705Z10510-3796+2557@nic.funet.fi> from "Juhana K Kouhia" at Jul 23, 98 04:17:03 pm Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"9MMBlB7HmEH.A.6gC.IJ0u1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/9 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 26 Jul 1998 16:50:49 +0200 Status: RO Hi! Could you perhaps subscribe the mailing list? It would be great if we could discuss there, since then - others could ask as well - the results would be archived and public available I'll cc this message there... > Look at Saol ("http://sound.media.mit.edu/~eds/mpeg4") for similar > software with (i) huge collection of processing modules, (ii) > a scheduler which also can handle MIDI. Source is in public domain > and the thing is a part of MPEG4 standard. > > Other similar softwares are: PD, Csound, Sapphire, Nyquist, Ptolemy, > whatever. Look at "http://www.bright.net/~dlphilp/linux_soundapps.html". Ok, these look interesting. I have at least checked out the Saol stuff, and it really gives me lots of ideas. ;) > A few comments (but not flames) on your further tasks: > > > - Module normalization > [ ... ] > > A better idea would be a module mixing the two signals, sig1 at a level > > of x percent, sig2 at a level of (100-x) percent. > > Wrong! Wrong! > The correct way is to just add the signals together: x + y. > You should also compute with floats if not already. > > It doesn't matter if the signal goes over the range [-1,1]. > It is cut (saturated) between -1 and 1 just before converting > the signal to D/A card. > > Each filter should have normalized output: unity gain. Then input > in range [-a,a] stays in range [-a,a]. > > If mixing (as in a mix, a reverb or an echo) brings the signal out of > range, it is perfectly ok. In practize, some module following the > overflowed signal may bring the level to the wanted range. Such module > is, for example, a gain module which adjustment is left to the user. > > You also need a signal level meter module with ability to show the > maximum level of the whole signal. Or such. Ok - that sounds reasonable. Does this still work when you have feedback loops? I thought that if you just added signals, it would (often?) happen that the signal grows to an arbitary level, so that no matter what gain module you add, the D/A signal will definitely leave the defined range. Another point is that I'd like to connect every module with every other. Now see a delay module: it simply can only delay positive times. So you could not connect a signal directly to the "delay this time"-port of a delay module. > > you mix the modules wrong. (And some accept ranges between 0 and 1, > > while others accept ranges between -1 and 1, which is _not_ the way > > Range from -1 to 1 is correct. > > If you have questions please ask. I'm not a MIDI expert, though. I have two questions that come to my mind right now: - You know these RC-Modules? An inductivity (coil? I am no native speaker), and a condenser (?) let pass one particular frequency optimally and those that differ not so optimal. Is there anything I can say about gain there? I use differences between signals there (the difference in 1/44000 second, that is the difference between two sampling bytes). Does it depend on these differences? The problem I have is that the lower my resonance frequency is, the more of my sampling difference gets into the field (perhaps wrong approach/ missed something?), and the louder the output gets. - Another point is, KSynth currently calculates one sampling byte in each turn. If you have a synthesis model that consists of ten modules, then KSynth calculates one sampling byte with the first module, then one sampling byte withe the second module, then ... until it has done all ten modules. Then it starts over again. That means it is able to handle even short delays that are feedbacked gracefully. You can simulate a flanger in KSynth pretty good now. But then again, it hits the performance badly. I suppose if we could calculate larger numbers of sampling bytes / turns, such as 32, which would be about 1/1000 sec (1ms), then we could get a lot better per- formance. But then we could not delay a signal shorter than 1ms and use it for feedback. Do you think this would impact overall usability of KSynth? Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Jul 26 20:48:44 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA12255 for ; Sun, 26 Jul 1998 20:48:43 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106113-18753>; Sun, 26 Jul 1998 20:49:22 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@kde.org In-reply-to: <199807261449.QAA11555@space.twc.de> (message from Stefan Westerfeld on Sun, 26 Jul 1998 16:49:27 +0200 (CEST)) Subject: Re: KSynth feedback Message-Id: <19980726184850Z20413-14900+2801@nic.funet.fi> Date: Sun, 26 Jul 1998 21:48:49 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"PKVtslQoeAO.A.AOH.yo3u1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/10 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 26 Jul 1998 20:49:22 +0200 Status: RO >Could you perhaps subscribe the mailing list? Done! >Ok - that sounds reasonable. Does this still work when you have feedback >loops? I thought that if you just added signals, it would (often?) happen >that the signal grows to an arbitary level, so that no matter what gain >module you add, the D/A signal will definitely leave the defined range. That is then an unstable system. Mixing 100 channels to one might produce high values but practically there is no problem. How analog mixers do it? I think they distord the output. If we want simulate specially the analog devices we should do the same, right? >Another point is that I'd like to connect every module with every other. With Saol, the user can do pretty complex systems. >Now see a delay module: it simply can only delay positive times. So you >could not connect a signal directly to the "delay this time"-port of >a delay module. Well, since delay accept only positive values you should either produce a runtime error or truncate the negative values to 0. I think truncating is better. >- You know these RC-Modules? An inductivity (coil? I am no native speaker), No. Sorry. There are filter designs in journals. Particularly good is a three part paper "Effect Design" in Journal of AES published around December 1997. The author has worked in Lexicon and Emu. There is even a high quality reverb described. It has some analog sounding filters too. Take my code "http://www.funet.fi/~kouhia/music.tar.gz" and extract a couple of other filters from there. You can test filters with my code too. >But then we could not delay a signal shorter than 1ms and >use it for feedback. You can delay the signal shorter than 1 ms. Only the feedback causes problems, I see. Csound works like this and is widely used anyway; control period is often just 10 samples. Saol uses sample-by-sample approach and is slow too --- they are looking for a better, hybrid method: some compute N-by-N samples, some 1-by-1 sample. You could use the faster approach but make important feedback effects in C as a module. If a plain reverb is a module then complicated reverb effects needs only delays larger than 1 ms. I'm in Audiotechque mailing list. That should be a wave editor. Problems are: (i) it is very dependent on GNOME, (ii) it is almost freezed temporarily because main authors are writing GNOME now. If interested, look at my design document (40+ pages wishlist :-) at "http://www.funet.fi/~kouhia/waves.html". It is a far from ready. Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Jul 27 12:25:15 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id MAA13408 for ; Mon, 27 Jul 1998 12:25:14 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106169-21252>; Mon, 27 Jul 1998 12:25:54 +0200 Sender: pjl@bath.ac.uk Message-ID: <35BC55E0.794B@bath.ac.uk> Date: Mon, 27 Jul 1998 11:26:40 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback References: <19980726184850Z20413-14900+2801@nic.funet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"W-LO2btlLFP.A.yhH.yWFv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/11 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 27 Jul 1998 12:25:54 +0200 Status: RO Hello, > >Ok - that sounds reasonable. Does this still work when you have feedback > >loops? I thought that if you just added signals, it would (often?) happen > >that the signal grows to an arbitary level, so that no matter what gain > >module you add, the D/A signal will definitely leave the defined range. > > That is then an unstable system. > Mixing 100 channels to one might produce high values but practically > there is no problem. How analog mixers do it? I think they distord > the output. If we want simulate specially the analog devices we should > do the same, right? My 2 cents. Do it all using doubles and only convert to 16 bit stuff at the very end. > >- You know these RC-Modules? An inductivity (coil? I am no native speaker), An LRC module (damped resonator) can be modelled using a seconded order digital filter. The input is a sum of the output delayed once and delayed twice. > You can delay the signal shorter than 1 ms. Only the feedback causes > problems, I see. Csound works like this and is widely used anyway; > control period is often just 10 samples. Saol uses sample-by-sample > approach and is slow too --- they are looking for a better, hybrid method: > some compute N-by-N samples, some 1-by-1 sample. If you use N samples then you need to be careful that that you do not introduce any artifacts due to the sample length. I presume we are interested in real time stuff here ? > You could use the faster approach but make important feedback > effects in C as a module. If a plain reverb is a module then > complicated reverb effects needs only delays larger than 1 ms. > > I'm in Audiotechque mailing list. That should be a wave editor. > Problems are: (i) it is very dependent on GNOME, (ii) it is almost > freezed temporarily because main authors are writing GNOME now. > > If interested, look at my design document (40+ pages wishlist :-) > at "http://www.funet.fi/~kouhia/waves.html". It is a far from ready. I will do that. I have put a Linux port of Perry Cooks physical modelling tool kit at ftp://ftp.bath.ac.uk/pub/eespjl/cantor/stk.tgz This is a collection of filters, FM synthesis, delay lines etc. It is very easy to understand (compared to the csound source !!!!). The TestALLUSRRT demos various instruments playing tunes. This scheme uses the single sample message , the number of voices limit will depend on the complexity of the instrument and of course the speed of the machine. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Jul 27 18:45:57 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id SAA13919 for ; Mon, 27 Jul 1998 18:45:55 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106295-2380>; Mon, 27 Jul 1998 18:46:15 +0200 Message-ID: <19980727184437.24087@space.twc.de> Date: Mon, 27 Jul 1998 18:44:37 +0200 From: Stefan Westerfeld To: ksynth@kde.org Subject: Design issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"9-9FB7RmpQM.A.y8.W7Kv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/12 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 27 Jul 1998 18:46:15 +0200 Status: RO Hi! I have thought for quite some time, what design would be good for KSynth for further development. Perhaps it helps if I just try to give you a short view, because being alone and thinking about such things, you often don't see everything. The things that the new design should be able to solve better are: - File format: currently KSynth saves it's files in some kind of .INI-File like (KConfig) format. This means that * the file format is bound to KDE * you can't implement saving of samples in the file * the synthesizer core (synthesizer) can't operate without the GUI since it can't read its files - Graphic representation and editing of complex structures, such as envelopes is not possible * I thought about implementing a FastTracker like envelope system, with loop points, but it wouldn't be possible to specify such an envelope just by specifying a limited number of floats - Dynamic restructuring and "template classes" are not possible * Dynamic restructuring: a program change in your midi file occures and you don't need your piano synthesis any longer, but drum synthesis. The modules for piano synthesis should be thrown out on the fly, and those for drum synthesis loaded in * template classes: imagine you have built up a module that plays a sequence on piano, mixes it, reverbs it and applies nice effects to it. Now you want to replace the piano instrument by a trumpete instrument, perhaps at runtime with a switch on your gui. - Extending KSynth to be capable to run as effect processor for third party software like audiotechque or kwave/ksoundsys. * GUI stuff should be there for configuring the filter, as well as an abstract definition what is a filter, so that KSynth could look up all the filters it can provide to the third party software. Of course KSynth would only provide these plugins Juhana calls realtime plugins (as opposed to direct plugins which see the entire sampling data). But it could provide a convenient way to compose plugins out of multiple components, including a GUI builder and such. Now to what I think would be necessary, to come closer to solving all of the mentioned problems: Currently, KSynth only uses one major class/type: synthesis modules. They get all data as floats, and output it as floats. The floats are directly conencted via pointers. (E.g. the out[2] pointer of synthesis module #1 points to the same float as the in[1] pointer of synthesis module #2, making a connection between). One can say that this one class was non visual. What I propose is to provide 5 classes in the future: - types - interfaces - synthesis modules - editors > visual - viewers > visual Explaining these: 1. types Types would be what floats are now: the way you connect modules. The elegant thing is, that since types are no longer limited to floats, you could specify anything you like as a type, for instance a float, or a FastTracker-Envelope, or a midi event, or a sample form, or a sequence, that contains multiple notes, such as A-4;C-4;D-4;E-4;. Every type should provide - a save to stream, load from stream function - a name for finding/using it - a constructor/destructor - the necessary interface to access its data - possible a way to access its data directly without interface functions (such as accessing a float again via pointer, saving the performance impact using getValue or setValue functions) Connections would be typed, allowing you to connect a module that generates an FastTracker-Envelope to one that uses one to scale its waves. 2. interfaces Interfaces would specify a name, and which ports they have. Ports should have information about their name, how they are typed, and what directory they go. example for a delay interface port #1: in signal, type float port #2: in time, type float port #3: out signal, type float example for a fasttracker style envelope scaler port #1: in midi, type midievent port #2: in envelope, type fasttracker_envelope port #3: in signal, type float port #4: out signal, type float Interfaces should be independant of their implementations, while implentations can either be single modules or structures of modules. 3. modules A module should - implement an interface - have a name - have a start/stop function for initialization and deinitialization - have a calculation function for the actual calculation 4. editors An editor is a visual control that edits elements of a certain type. For one type may exist multiple editors, such as for a float a simple text field or a scroll bar. Editors should be the only interface from the user to the synthesis module when specifying values or modifying them (such as specifying the length of a delay or the envelope an instrument should use for scaling). 5. viewers A viewer is a visual control that displays types. You could use viewers to display for instance midi events as they enter the synthesizer, the level of signals (those nice led bars you got on your amplifier at home), ... All five classes should be extendable using plugins, e.g. you don't have to touch the KSynth source to add new. While types, modules, editors and viewers would require the use of a C(++) compiler, specifying new interfaces should be possible without. Editors and viewers would probably require you to use your-favourite- toolkit(tm) as well. Ok - this should be enough to describe about the things that I'd like to do, feedback welcome. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Jul 27 19:08:39 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA13999 for ; Mon, 27 Jul 1998 19:08:37 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106236-2384>; Mon, 27 Jul 1998 19:09:26 +0200 Message-ID: <19980727190747.34401@space.twc.de> Date: Mon, 27 Jul 1998 19:07:47 +0200 From: Stefan Westerfeld To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback References: <199807261449.QAA11555@space.twc.de> <19980726184850Z20413-14900+2801@nic.funet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19980726184850Z20413-14900+2801@nic.funet.fi>; from Juhana K Kouhia on Sun, Jul 26, 1998 at 09:48:49PM +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"SguVEbvPz4D.A.sMB.GRLv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/13 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 27 Jul 1998 19:09:26 +0200 Status: RO Hi! On Sun, Jul 26, 1998 at 09:48:49PM +0300, Juhana K Kouhia wrote: > >Ok - that sounds reasonable. Does this still work when you have feedback > >loops? I thought that if you just added signals, it would (often?) happen > >that the signal grows to an arbitary level, so that no matter what gain > >module you add, the D/A signal will definitely leave the defined range. > > That is then an unstable system. > Mixing 100 channels to one might produce high values but practically > there is no problem. How analog mixers do it? I think they distord > the output. If we want simulate specially the analog devices we should > do the same, right? I am convinced ;) > >Another point is that I'd like to connect every module with every other. > > With Saol, the user can do pretty complex systems. With plain C as well. The problem is that I think about users that can't count from one to three (not meant seriously, but think a little in that direction). Finally they are neither matematicans nor programmers. They are simply musicians which use the system. And for those I'd like to have something where you can't plug together modules "the wrong way", e.g. where you get runtime errors and that kind of stuff. A friend of mine complained about generator (some of our windows counterparts), because he simply didn't like to always adjust various kinds of signal levels adjusted so that the output was right. He wanted the real click and go feeling, not the think, click then think again feeling ;) > [..] > > >But then we could not delay a signal shorter than 1ms and > >use it for feedback. > > You can delay the signal shorter than 1 ms. Only the feedback causes > problems, I see. Csound works like this and is widely used anyway; > control period is often just 10 samples. Saol uses sample-by-sample > approach and is slow too --- they are looking for a better, hybrid method: > some compute N-by-N samples, some 1-by-1 sample. Ok, I have thought about a way to do flexible length signal piping, resulting in an on demand resizing range between 1-by-1 to N-by-N. But it wouldn't work well with the type abstraction stuff I wrote about, and not with the current scheduling code. > You could use the faster approach but make important feedback > effects in C as a module. If a plain reverb is a module then > complicated reverb effects needs only delays larger than 1 ms. Yes, it seems to be the way to go. > I'm in Audiotechque mailing list. That should be a wave editor. > Problems are: (i) it is very dependent on GNOME, (ii) it is almost > freezed temporarily because main authors are writing GNOME now. Yes, I'd like to work together with Audiotechque as well, perhaps that the real time plugins could be writting in KSynth, so that the filters were available to everyone using a particular interface. Since KSynth will require to have a GUI builder as well, no work would be wasted, only saved. ;) I think that such projects should be made independant from the GUI. So should lyx, so should gimp so should ksynth. If someone will help me out doing the Gnome/Gtk+ stuff, expect a GSynth to be there as soon as possible ;) I have done lot's of Corba for this and will try to keep porting possible. > If interested, look at my design document (40+ pages wishlist :-) > at "http://www.funet.fi/~kouhia/waves.html". It is a far from ready. Have looked at it. If they get implemented all that, I'll use it at once, and if I have to compile every Gnome source from scratch ;) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Jul 27 20:01:45 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA14114 for ; Mon, 27 Jul 1998 20:01:43 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106143-5699>; Mon, 27 Jul 1998 20:02:22 +0200 Message-ID: <19980727192411.41121@space.twc.de> Date: Mon, 27 Jul 1998 19:24:11 +0200 From: Stefan Westerfeld To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback References: <19980726184850Z20413-14900+2801@nic.funet.fi> <35BC55E0.794B@bath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <35BC55E0.794B@bath.ac.uk>; from P.J.Leonard on Mon, Jul 27, 1998 at 11:26:40AM +0100 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"0WGJ-O-H93L.A.KnB.uCMv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/14 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 27 Jul 1998 20:02:22 +0200 Status: RO Hi! On Mon, Jul 27, 1998 at 11:26:40AM +0100, P.J.Leonard wrote: > My 2 cents. Do it all using doubles and only convert to 16 bit stuff at > the very end. KSynth uses floats already, it just does avoid producing signals out of the [-1;1] range with it. But yes, it'll do soon. > > >- You know these RC-Modules? An inductivity (coil? I am no native speaker), > > An LRC module (damped resonator) can be modelled using a seconded order > digital filter. The input is a sum of the output delayed once and > delayed twice. That means? out(x) = in(x) + in(x+1) > > You can delay the signal shorter than 1 ms. Only the feedback causes > > problems, I see. Csound works like this and is widely used anyway; > > control period is often just 10 samples. Saol uses sample-by-sample > > approach and is slow too --- they are looking for a better, hybrid method: > > some compute N-by-N samples, some 1-by-1 sample. > > If you use N samples then you need to be careful that that you do not > introduce > any artifacts due to the sample length. I presume we are interested in > real time stuff > here ? The problem is speed. If you have ten synthesis modules and schedule them X times, while calling each of the ten after another, and every of them calculates one sample, it's much slower than calling each of the ten modules X/N times while each does N samples. This does not alter calculations, as long as just the loop is done internally and the code inside looks the same, and there is no delay below N samples which is feed back into the input again. As well, it would require rewriting the scheduling stuff. Currently KSynth just schedules all modules more or less random order, which is quite irrelevant for the 1-BY-1 approach, since it only occasionally introduces 1 sample delays, while in the N-BY-N approach it might be a problem. I'm not sure, but I suppose you had to analyze the whole structure carefully depending on how you implement the stuff. > I have put a Linux port of Perry Cooks physical modelling tool kit at > > ftp://ftp.bath.ac.uk/pub/eespjl/cantor/stk.tgz > > This is a collection of filters, FM synthesis, delay lines etc. It is > very > easy to understand (compared to the csound source !!!!). The > TestALLUSRRT > demos various instruments playing tunes. This scheme uses the single > sample > message , the number of voices limit will depend on the complexity of > the instrument > and of course the speed of the machine. Just thought about priorities again (sure no flame, it's cool that we have references now to about anything where we could steal code from ;): It would be really great if we could agree upon the "how" KSynth should be built, before we start throwing in the various bits and filters. Of course, it will take some experiments to see "how" it works best, but then again, if we have a good interface to just throw stuff in, about anybody can do it without being dependant on the work of others. If we put in ten filters now, the work will probably be lost, since we'd have to do it again when KSynth goes to an 32-BY-32 model with type abstraction. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Jul 27 22:56:42 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id WAA14623 for ; Mon, 27 Jul 1998 22:56:41 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106298-5700>; Mon, 27 Jul 1998 22:57:16 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@alpha.tat.physik.uni-tuebingen.de In-reply-to: <19980727192411.41121@space.twc.de> (message from Stefan Westerfeld on Mon, 27 Jul 1998 19:24:11 +0200) Subject: Re: KSynth feedback Message-Id: <19980727205604Z1112-9853+2853@nic.funet.fi> Date: Mon, 27 Jul 1998 23:56:03 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"OfmNeuPic3M.A.m9D.kmOv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/15 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 27 Jul 1998 22:57:16 +0200 Status: RO >From: Stefan Westerfeld > >It would be really great if we could agree upon the "how" KSynth should >be built, before we start throwing in the various bits and filters. How about if the control rate is given and each module should be able to work with any control rate? However, I suspect that to get really efficient realtime system, we should divide the total computation resources among all modules: some modules need less, some more. The main advantage is: a FFT module can compute 512 (say) samples by using computing resources from all its splices. Then how about putting each module to its own process/thread? Perhaps later this kind of system.... Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 11:25:58 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA15566 for ; Tue, 28 Jul 1998 11:25:56 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106274-29582>; Tue, 28 Jul 1998 11:25:32 +0200 Sender: pjl@bath.ac.uk Message-ID: <35BD98CA.167E@bath.ac.uk> Date: Tue, 28 Jul 1998 10:24:26 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Design issues References: <19980727184437.24087@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"gMr5yq5cmYM.A.ZcF.MkZv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/16 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 11:25:32 +0200 Status: RO Hello, Here are some random comments. Stefan Westerfeld wrote: > Currently, KSynth only uses one major class/type: synthesis modules. They > get all data as floats, and output it as floats. The floats are directly > conencted via pointers. (E.g. the out[2] pointer of synthesis module #1 > points to the same float as the in[1] pointer of synthesis module #2, > making a connection between). I would recommend doubles. floats will suffer from round off during processing. > One can say that this one class was non visual. > > What I propose is to provide 5 classes in the future: > > - types > - interfaces > - synthesis modules > - editors > visual > - viewers > visual > > Explaining these: > > 1. types > > Types would be what floats are now: the way you connect modules. The > elegant thing is, that since types are no longer limited to floats, you > could specify anything you like as a type, for instance a float, or > a FastTracker-Envelope, or a midi event, or a sample form, or a sequence, > that contains multiple notes, such as A-4;C-4;D-4;E-4;. This means a module is going to do it's own sequencing ? I would keep the sequencing seperate from the sound production module. > Every type should provide > > - a save to stream, load from stream function > - a name for finding/using it An integer handle and a type ? > - a constructor/destructor > - the necessary interface to access its data > - possible a way to access its data directly without interface functions > (such as accessing a float again via pointer, saving the performance > impact using getValue or setValue functions) Presumably the GUI does not need to be that effecient ? This is all wrapped up in CORBA ? Do your synth components talk via CORBA as well ? If so it is going to be very slooowwww ? > Connections would be typed, allowing you to connect a module that generates > an FastTracker-Envelope to one that uses one to scale its waves. > > 2. interfaces > > Interfaces would specify a name, and which ports they have. > > Ports should have information about their name, how they are typed, and > what directory they go. > > example for a delay interface > > port #1: in signal, type float > port #2: in time, type float > port #3: out signal, type float > > example for a fasttracker style envelope scaler > > port #1: in midi, type midievent > port #2: in envelope, type fasttracker_envelope > port #3: in signal, type float > port #4: out signal, type float DO these live in a ksynth description file ? e.g. ---- component descriptions module: piano port #1: in midi, type midi port #2: out signal, type float module: reverb port #1: in depth,type double, range 0-100, unit percent note the addition of range and unit for the GUI to feed off. ---- instrument descriptions The job of the GUI is to build a connection matix from these components. This could be in the form instrument: honky-tonk : piano,chorus % define instument and it's components instrument:midi -> piano:midi % midi in events go to the piano chorus:out -> instrument:out % take signal out from chorus out instrument:filter[midi-in CNTRL CHORUS]:out -> chorus:depth % route a midi effect to the chorus depth piano:out -> chorus->in % feed piano into the chorus Note an instument could also be used as a component. --- Finally we have a patch file that associates midi program-bank pairs with instruments. 0:0 honk-tonk 0:1 wierd-piano Now the users of say cantor can load instruments into the synth module using program-bank pairs. > Interfaces should be independant of their implementations, while > implentations can either be single modules or structures of modules. > > 3. modules > > A module should > > - implement an interface > - have a name > - have a start/stop function for initialization and deinitialization > - have a calculation function for the actual calculation > > 4. editors > > An editor is a visual control that edits elements of a certain type. For > one type may exist multiple editors, such as for a float a simple text > field or a scroll bar. > > Editors should be the only interface from the user to the synthesis module > when specifying values or modifying them (such as specifying the length > of a delay or the envelope an instrument should use for scaling). Do modules need to inform any interested parties (viewers) that they have been modified ? > > 5. viewers > > A viewer is a visual control that displays types. You could use viewers > to display for instance midi events as they enter the synthesizer, the > level of signals (those nice led bars you got on your amplifier at home), > > ... > > All five classes should be extendable using plugins, e.g. you don't have > to touch the KSynth source to add new. > > While types, modules, editors and viewers would require the use of a C(++) > compiler, specifying new interfaces should be possible without. > > Editors and viewers would probably require you to use your-favourite- > toolkit(tm) as well. > > Ok - this should be enough to describe about the things that I'd like to > do, feedback welcome. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 11:56:45 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA15582 for ; Tue, 28 Jul 1998 11:56:44 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106255-29584>; Tue, 28 Jul 1998 11:57:15 +0200 X-Lotus-FromDomain: EMPRISE From: hlapp@emprise.de To: ksynth@kde.org Message-ID: Date: Tue, 28 Jul 1998 11:55:10 +0200 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"SNyHqRp-z_C.A.7IG.7Bav1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Unidentified subject! Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/17 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 11:57:15 +0200 Status: RO Harald Lapp@EMPRISE 28.07.98 11:55 hi! >> 1. types >> >> Types would be what floats are now: the way you connect modules. The >> elegant thing is, that since types are no longer limited to floats, you >> could specify anything you like as a type, for instance a float, or >> a FastTracker-Envelope, or a midi event, or a sample form, or a sequence, >> that contains multiple notes, such as A-4;C-4;D-4;E-4;. > This means a module is going to do it's own sequencing ? I would keep > the sequencing > seperate from the sound production module. as i'm not a good coder, but a musician (also not good ;-)... i think it's better, when each module has it's own sequencer. and really every module should have a sequencer. let me explain why: i (as musician) want to have total control of the music. i want to have control to every parameter not only do "live"-sequencing but also typing a sequence direct in an editor. splitting the sequencer from the modules would be not that comfortable. imagine you have only one sequencer,... there are 100eds of channels, where you set the parameter (like for one filter, that would be e.g. cutoff, resonance, filter-type, maybe output-volume,....) i think every module should have it's own sequencer, so a user can just click on the module, to go directly to the part, where he can directly control the machine. of course there must be two parts of a sequencer (and maybe that is this, what you meant)... one pattern-sequencer for every module and one sequencer, where you can call the patterns of a module. ... but maybe this is to much "tracker"-like... cu <-harald From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 12:01:56 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id MAA15620 for ; Tue, 28 Jul 1998 12:01:54 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106273-29584>; Tue, 28 Jul 1998 12:02:47 +0200 Sender: pjl@bath.ac.uk Message-ID: <35BDA1E1.2781@bath.ac.uk> Date: Tue, 28 Jul 1998 11:03:13 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback References: <19980726184850Z20413-14900+2801@nic.funet.fi> <35BC55E0.794B@bath.ac.uk> <19980727192411.41121@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"sw7hvSdBXiE.A.YLG.HHav1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/18 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 12:02:47 +0200 Status: RO Stefan Westerfeld wrote: > > Hi! > > On Mon, Jul 27, 1998 at 11:26:40AM +0100, P.J.Leonard wrote: > > My 2 cents. Do it all using doubles and only convert to 16 bit stuff at > > the very end. > KSynth uses floats already, it just does avoid producing signals out of > the [-1;1] range with it. But yes, it'll do soon. > > > > >- You know these RC-Modules? An inductivity (coil? I am no native speaker), > > > > An LRC module (damped resonator) can be modelled using a seconded order > > digital filter. The input is a sum of the output delayed once and > > delayed twice. > > That means? out(x) = in(x) + in(x+1) I think out(x) = gain*in(x) + alpha * out(x-1) + beata* out(x-2) Here is the guts of a class that does just this. /*******************************************/ /* Two Pole Filter Class, */ /* by Perry R. Cook, 1995-96 */ /* See books on filters to understand */ /* more about how this works. Nothing */ /* out of the ordinary in this version. */ /*******************************************/ #include "TwoPole.h" TwoPole :: TwoPole() : Filter() { outputs = (MY_FLOAT *) malloc(2 * MY_FLOAT_SIZE); poleCoeffs[0] = 0.0; poleCoeffs[1] = 0.0; gain = 1.0; this->clear(); } TwoPole :: ~TwoPole() { // free(inputs); free(outputs); } void TwoPole :: clear() { outputs[0] = 0.0; outputs[1] = 0.0; lastOutput = 0.0; } void TwoPole :: setPoleCoeffs(MY_FLOAT *coeffs) { poleCoeffs[0] = coeffs[0]; poleCoeffs[1] = coeffs[1]; } void TwoPole :: setFreqAndReson(MY_FLOAT freq, MY_FLOAT reson) { poleCoeffs[1] = - (reson * reson); poleCoeffs[0] = 2.0 * reson * cos(TWO_PI * freq / SRATE); } void TwoPole :: setGain(MY_FLOAT aValue) { gain = aValue; } MY_FLOAT TwoPole :: tick(MY_FLOAT sample) /* Perform Filter Operation */ { /* TwoPole is a two pole filter (duh!) */ MY_FLOAT temp; /* Look it up in your favorite DSP text */ temp = sample * gain; temp += poleCoeffs[0] * outputs[0]; temp += poleCoeffs[1] * outputs[1]; outputs[1] = outputs[0]; outputs[0] = temp; lastOutput = outputs[0]; return lastOutput; } A general filter is out(x) = gain*in(x) + SUMOF a(i) * out(x-i) i-1,N This is the basis of linear predictive coding. > > > You can delay the signal shorter than 1 ms. Only the feedback causes > > > problems, I see. Csound works like this and is widely used anyway; > > > control period is often just 10 samples. Saol uses sample-by-sample > > > approach and is slow too --- they are looking for a better, hybrid method: > > > some compute N-by-N samples, some 1-by-1 sample. > > > > If you use N samples then you need to be careful that that you do not > > introduce > > any artifacts due to the sample length. I presume we are interested in > > real time stuff > > here ? > > The problem is speed. If you have ten synthesis modules and schedule them > X times, while calling each of the ten after another, and every of them > calculates one sample, it's much slower than calling each of the ten > modules X/N times while each does N samples. > > This does not alter calculations, as long as just the loop is done internally > and the code inside looks the same, and there is no delay below N samples > which is feed back into the input again. This is OK providing there are no tight feed back. If your building blocks are fine grain such that it is possible to feed the out put of a component back to its own input via a filter then using a block length of more than one is not feasible. We have a difficult design question. 1. Sample size of 1 allows fine grain components and great connection flexibility. This also maps onto a multiprocessor system ? 2. Sample size > 1 is fast but modules need to made cleverer and it leads to less flexibility. Maybe we need to allow a mixture of the 2 types. Sections of the synthesis structure that require tight feed back. For example the structure of a reed instrument might be + <-filter------ reed -> cyclic_delay -|--- reverb ---> output The reed delay and filter are best implemented with a single sample. The reverb on the other hand is not fed back so it could be implmented with blocks of samples. But what if we decide to try + <-filter------ reed -> cyclic_delay -|--- reverb ---> output +-----------------------/ Now we would like the reverb to become single sample!!! I have looked a virtual waves (WINDOZE) and it does not allow any feedback (to avoid this problem). My vote goes for the single sample scheme. > As well, it would require rewriting the scheduling stuff. Currently > KSynth just schedules all modules more or less random order, which is > quite irrelevant for the 1-BY-1 approach, since it only occasionally > introduces 1 sample delays, while in the N-BY-N approach it might be > a problem. I was going to have the scheduler analysis the connectivity. It would then work out the correct order to fire the components. Firing a component makes it look at its inputs and ensure that its outputs are up to date. The flow of information is done by each component observing it's inputs. > I'm not sure, but I suppose you had to analyze the whole structure > carefully depending on how you implement the stuff. Yep :-) > > I have put a Linux port of Perry Cooks physical modelling tool kit at > > > > ftp://ftp.bath.ac.uk/pub/eespjl/cantor/stk.tgz > > > > This is a collection of filters, FM synthesis, delay lines etc. It is > > very > > easy to understand (compared to the csound source !!!!). The > > TestALLUSRRT > > demos various instruments playing tunes. This scheme uses the single > > sample > > message , the number of voices limit will depend on the complexity of > > the instrument > > and of course the speed of the machine. > > Just thought about priorities again (sure no flame, it's cool that we > have references now to about anything where we could steal code from ;): I suggest you download it and listen to the sounds. IMHO it is pretty cool and illustrates what is possible with the single sample scheme. > It would be really great if we could agree upon the "how" KSynth should > be built, before we start throwing in the various bits and filters. Of > course, it will take some experiments to see "how" it works best, but > then again, if we have a good interface to just throw stuff in, about > anybody can do it without being dependant on the work of others. > > If we put in ten filters now, the work will probably be lost, since > we'd have to do it again when KSynth goes to an 32-BY-32 model with > type abstraction. I repeat my vote for the single sample method based on simplicity and flexibility. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 13:03:22 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id NAA15693 for ; Tue, 28 Jul 1998 13:03:20 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106252-29579>; Tue, 28 Jul 1998 13:04:13 +0200 Sender: pjl@bath.ac.uk Message-ID: <35BDB04C.794B@bath.ac.uk> Date: Tue, 28 Jul 1998 12:04:54 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Unidentified subject! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"iMThEKW-rcJ.A.YYH.tAbv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/19 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 13:04:13 +0200 Status: RO hlapp@emprise.de wrote: > > This means a module is going to do it's own sequencing ? I would keep > > the sequencing > > seperate from the sound production module. > > as i'm not a good coder, but a musician (also not good ;-)... i think it's > better, when each > module has it's own sequencer. and really every module should have a > sequencer. let me explain > why: I am listening :-) > i (as musician) want to have total control of the music. i want to have > control to > every parameter not only do "live"-sequencing but also typing a sequence > direct in > an editor. splitting the sequencer from the modules would be not that > comfortable. > > imagine you have only one sequencer,... there are 100eds of channels, where > you set the parameter > (like for one filter, that would be e.g. cutoff, resonance, filter-type, > maybe output-volume,....) > i think every module should have it's own sequencer, so a user can just > click on the module, > to go directly to the part, where he can directly control the machine. > > of course there must be two parts of a sequencer (and maybe that is this, > what you meant)... > one pattern-sequencer for every module and one sequencer, where you can > call the patterns of a > module. > > ... but maybe this is to much "tracker"-like... Terms !! We need to define our terms. Here are the classes that are part of my cantor sequencer structure. Device -- responds to events e.g. noteon , set filter, set volumne etc. can create a list of effects (name range prototype event) for the user to use. This corresponds to a Module ? Does not know about the song tempo. Event -- Exists only at a point in time (see above), An event is Device / Channel / Type / data In my scheme events are sent in real time so no need for time stamps. The following are absract bases Gesture -- Is a Sequence. Sequence -- Can create a sequencer given a player(voice). Sequencer -- Absract interface to a linear seqeunce of events. Provides time of next exectution. Execution typically execute sends a midiout event to a player. Player -- Maps midiout events to a device/channel. So far Gestures are, EffectEvent -- e.g. set volume Note -- it's sequencer first sends a note on then a note off. Sweep -- it's sequencer produces a stream of events from a start to a finish value. A Phrase. is a sequence of Gestures A Track is a seqeunce of Phrases. A track has a Player ------ Using these definitions/structure I can not see why a Device/module shoudl have it's own sequencer ? Unless it is to implemenent real-time (compared to song ticks) modulation of filters. In which case I aggree that each module should provide an editing interface. Making this interface absract so new devices can be plugged in without having to build specialised GUI components will be fun :-) cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 13:14:23 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id NAA15701 for ; Tue, 28 Jul 1998 13:14:21 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106252-29584>; Tue, 28 Jul 1998 13:15:14 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@alpha.tat.physik.uni-tuebingen.de In-reply-to: <35BDA1E1.2781@bath.ac.uk> (P.J.Leonard@bath.ac.uk) Subject: Re: KSynth feedback Message-Id: <19980728111431Z10242-9853+2899@nic.funet.fi> Date: Tue, 28 Jul 1998 14:14:27 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"wfml_rj4djB.A.OiH.CLbv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/20 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 13:15:14 +0200 Status: RO >From: "P.J.Leonard" > > Maybe we need to allow a mixture of the 2 types. My suggestion on saol-dev mailing list was to use graph theory results to find what nodes needs 1-by-1 processing and what nodes can be computed in larger pieces. I proposed something like examining if a node is in the same loop with a node needing 1-by-1 processing, then that node too should be computed with 1-by-1 processing. Note that a loop can be computed in n-by-n blocks if we allow an implicit delay by n samples in the loop. If we want thight 1 sample delay then we should compute 1-by-1 basis, and if we don't want even that one sample delay, then we should solve physical equations in mathematical meanings. Should we leave room for each of these methods? An external (to the flow network) system could analyze the system fully before any computations. Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 14:12:49 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id OAA15758 for ; Tue, 28 Jul 1998 14:12:48 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106155-29582>; Tue, 28 Jul 1998 14:13:34 +0200 Sender: pjl@bath.ac.uk Message-ID: <35BDC091.59E2@bath.ac.uk> Date: Tue, 28 Jul 1998 13:14:10 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback References: <19980728111431Z10242-9853+2899@nic.funet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"bZJrjaE_x6J.A.iM.uBcv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/21 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 14:13:34 +0200 Status: RO Juhana K Kouhia wrote: > My suggestion on saol-dev mailing list was to use graph theory results > to find what nodes needs 1-by-1 processing and what nodes can be > computed in larger pieces. I proposed something like examining if > a node is in the same loop with a node needing 1-by-1 processing, > then that node too should be computed with 1-by-1 processing. > > Note that a loop can be computed in n-by-n blocks if we allow an > implicit delay by n samples in the loop. If we want thight 1 sample > delay then we should compute 1-by-1 basis, and if we don't want even > that one sample delay, then we should solve physical equations in > mathematical meanings. > > Should we leave room for each of these methods? Interesting. This approach would most certainly be optimal in terms of CPU usage. However, the analysis would have to be pretty dam smart to figure out the best way to implement a given configuration. In the 1-by-1 scheme each component can be a black box. In the analysis scheme I get the feeling that the analysis program needs detailed knowledge of each component. >From an OO point of view this would be bad news because the analysis module is coupled to all the components making it a bit heavy. Maybe I am wrong ? > An external (to the flow network) system could analyze the system > fully before any computations. What are the operations on the data flow ? How fine grain do you go ? Elemententary operations. arithmetic +-*/ (out = in_1 + in_2) delay (out(t) = in (t-1) ) nonlinear (out(t) = any_func(in(t))) hysteresis (out(t) = any_func(in(t-t'))) ! t' >= 0 Now say we want to vocode a wave table sample of some waves with the formant of a real time analysis of a voice. Hum de dum . . . cheers Paul. p.s. One disadvantage of the 1-by-1 is the stability of some systems. It is equivalent to forward difference time stepping which is limited by the largest eigen value (fastest resonant mode) of the system. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Jul 28 19:56:56 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA16100 for ; Tue, 28 Jul 1998 19:56:55 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106231-8294>; Tue, 28 Jul 1998 19:50:37 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@alpha.tat.physik.uni-tuebingen.de In-reply-to: <35BDC091.59E2@bath.ac.uk> (P.J.Leonard@bath.ac.uk) Subject: Re: KSynth feedback Message-Id: <19980728144715Z1552-3796+2984@nic.funet.fi> Date: Tue, 28 Jul 1998 17:47:14 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"-3XQKPGTuCD.A.9dC.s9gv1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/22 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 28 Jul 1998 19:50:37 +0200 Status: RO >From: "P.J.Leonard" > >This approach would most certainly be optimal in terms of >CPU usage. However, the analysis would have to be pretty dam smart to >figure out the best way to implement a given configuration. In the 1-by-1 >scheme each component can be a black box. In the analysis scheme I get the >feeling that the analysis program needs detailed knowledge of each >component. I'm not sure but I think the only needed info would be the implicit delay we allow in the whole system. Please let me ask about the current system: does the system allow a convolution module, implemented with FFT, needing 512 input samples before anything can be outputted? I suspect the answer is no, and then your modules cannot truelly be black boxes, right? I have figured out my own flow system earlier but have not completed it. Between each module I have an "arc". "arcs" are ring buffers for storing the signals which cannot be processed immediately. For example, if the convoluted signal and the original signal are mixed together, then we would need a 512 sample length arc for both the original signal (just before the mixing module) and the convoluted signal (just before the mixing module). Otherwise, without the arc, we would have to mix the signals immediately, causing an implicit delay of 512 samples between the orig and the conv signals, and the mixing module should be able to receive 512 samples at once from the convolution module. In a system containing arcs, the module can have more freedom. But realtimeness causes problems: there is still a 512 sample delay at the output (but not between the orig and conv signals!) which causes that changes in convolution module parameters (if any) is heard after 512 samples. Right? Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Thu Jul 30 20:08:54 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA20488 for ; Thu, 30 Jul 1998 20:08:53 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106290-214>; Thu, 30 Jul 1998 20:09:26 +0200 From: Stefan Westerfeld Message-Id: <199807301807.UAA20483@space.twc.de> Subject: Re: KSynth feedback To: ksynth@alpha.tat.physik.uni-tuebingen.de Date: Thu, 30 Jul 1998 20:07:49 +0200 (CEST) In-Reply-To: <19980728144715Z1552-3796+2984@nic.funet.fi> from "Juhana K Kouhia" at Jul 28, 98 05:47:14 pm Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"IpBGbdzk2tD.A.buB.WbLw1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/23 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Thu, 30 Jul 1998 20:09:26 +0200 Status: O Content-Length: 4994 Lines: 117 Hi! > >This approach would most certainly be optimal in terms of > >CPU usage. However, the analysis would have to be pretty dam smart to > >figure out the best way to implement a given configuration. In the 1-by-1 > >scheme each component can be a black box. In the analysis scheme I get the > >feeling that the analysis program needs detailed knowledge of each > >component. > > I'm not sure but I think the only needed info would be the implicit > delay we allow in the whole system. > > Please let me ask about the current system: does the system allow > a convolution module, implemented with FFT, needing 512 input samples > before anything can be outputted? I suspect the answer is no, and then > your modules cannot truelly be black boxes, right? Currently, the system assumes that every module can perform it's calculations with no delay. This makes sense in an realtime environment I suppose. So if you wanted to implement your 512-BY-512 FFT module, you could only to the following: Your module would output the data 512 samples after getting it (and being a 512 samples delay module besides being a FFT module). So it would be sure to always have 512 bytes in a buffer when calculation is needed. To get nice mixing, you would need to use delay modules on the signals that did not go through the FFT module. > I have figured out my own flow system earlier but have not completed it. > Between each module I have an "arc". "arcs" are ring buffers for storing > the signals which cannot be processed immediately. > > For example, if the convoluted signal and the original signal are mixed > together, then we would need a 512 sample length arc for both the original > signal (just before the mixing module) and the convoluted signal (just > before the mixing module). > Otherwise, without the arc, we would have to mix the signals immediately, > causing an implicit delay of 512 samples between the orig and the conv > signals, and the mixing module should be able to receive 512 samples at > once from the convolution module. I thought about that. The question is, how do you determine when a module needs to be scheduled. And how do you avoid that modules that have no input signals do not overflow the arc they output their data to? The idea might not be too bad, if you - make the modules decide, whether they would like to do calculations, while giving them access to the status of all their input & output arcs - schedule the modules just randomly around - impose a limit onto the modules, so they can't write more than x signal values to an output arc, for x values of about 32 or so. (Yes, it doesn't make your 512 samples FFT module possible then, but it will run realtime quite nice). The question is how efficient can such a system be - when it would be possible to run this way and still be near optimal scheduling performance, I'd like it. It doesn't sound complicated to implement either. I am not sure though, whether in a large synthesis model with many modules all the arcs would be filled with data, making the overall delay actually a little large anyway (n*32 samples, where n is the amount of arcs between signal source and Synth_PLAY module). > In a system containing arcs, the module can have more freedom. > But realtimeness causes problems: there is still a 512 sample delay > at the output (but not between the orig and conv signals!) which causes > that changes in convolution module parameters (if any) is heard > after 512 samples. Right? Yes, 512 samples are quite heavy. Since KSynths midi support is based on a realtime approach, playing midi files would be broken as well, I guess. At least with the current algorithms. The KSynth communication model currently looks like this: 1. synth_server starts. It enters the CORBA idle loop (which is basically a select or something like that), the Synthesizer object is being provided to the outside world. 2. [...] various communication with ksbuild [...] 3. The user selects execute model. The model description is sent to the synth_server from ksbuild. 4. synth_server leaves its idle loop and builds up the modules. Some of them (Synth_PLAY) return file descriptors they want to get watched. 5. synth_server drops to idle loop again 6. Some time later some file descriptors need food. (Normally the audio output fd). synth_server leaves its idle loop. 7. synth_server executes 64 cycles of the modules (while scheduling one turn to each module, then the next turn to each module, and so on). The audio output fd gets some data. 8. The action starts at point 5 again. Only in the idle loop, KSynth is being able to receive events from the outside world, such as midibus events or a Stop-request. Later, there will be the point where the GUI elements can contact KSynth as well. This is because the CORBA calls from the outside world never interrupt running methods, they can only be processed from the idle loop. Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Jul 31 11:36:10 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA22372 for ; Fri, 31 Jul 1998 11:36:10 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106555-5297>; Fri, 31 Jul 1998 11:36:58 +0200 Date: Fri, 31 Jul 1998 11:35:14 +0200 From: huber@iamexwi.unibe.ch (the Physicist) Message-Id: <199807310935.LAA08574@giger.iamexwi.unibe.ch> To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Mico compile problem X-Sun-Charset: US-ASCII Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"rhvw2s_Ot7D.A.1uC.5AZw1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/24 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 31 Jul 1998 11:36:58 +0200 Status: O Content-Length: 631 Lines: 18 Yesterday I tried to compile ksynth for first experiments. So I first wanted to compile mico-2.1.1. As proposed on the mico-pages, I have gcc-2.7.2 (actually gcc-2.7.2.3) and libg++-2.7.2.8 All the same, I get the following error while compiling: c++ -I. -I../include -I/usr/local/src/KDE/mico/./include/ministl -O -I/usr/local/include -c dii.cc -o dii.o In file included from ../include/CORBA.h:92, from dii.cc:23: ../include/mico/sequence.h:269: Internal compiler error. ../include/mico/sequence.h:269: Please submit a full bug report to `bug-g++@prep.ai.mit.edu'. What am I doing wrong ? Thomas From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sat Aug 1 10:39:29 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA24333 for ; Sat, 1 Aug 1998 10:39:28 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106090-4654>; Sat, 1 Aug 1998 10:40:19 +0200 Date: Sat, 1 Aug 1998 09:40:13 +0100 (BST) From: P J Leonard To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback In-Reply-To: <19980728144715Z1552-3796+2984@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"YxpKdCkFZrE.A.-fB.zRtw1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/25 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sat, 1 Aug 1998 10:40:19 +0200 Status: O Content-Length: 1982 Lines: 46 On Tue, 28 Jul 1998, Juhana K Kouhia wrote: > >From: "P.J.Leonard" > > > >This approach would most certainly be optimal in terms of > >CPU usage. However, the analysis would have to be pretty dam smart to > >figure out the best way to implement a given configuration. In the 1-by-1 > >scheme each component can be a black box. In the analysis scheme I get the > >feeling that the analysis program needs detailed knowledge of each > >component. > > I'm not sure but I think the only needed info would be the implicit > delay we allow in the whole system. > > Please let me ask about the current system: does the system allow > a convolution module, implemented with FFT, needing 512 input samples > before anything can be outputted? I suspect the answer is no, and then > your modules cannot truelly be black boxes, right? > > I have figured out my own flow system earlier but have not completed it. > Between each module I have an "arc". "arcs" are ring buffers for storing > the signals which cannot be processed immediately. > > For example, if the convoluted signal and the original signal are mixed > together, then we would need a 512 sample length arc for both the original > signal (just before the mixing module) and the convoluted signal (just > before the mixing module). > Otherwise, without the arc, we would have to mix the signals immediately, > causing an implicit delay of 512 samples between the orig and the conv > signals, and the mixing module should be able to receive 512 samples at > once from the convolution module. > > In a system containing arcs, the module can have more freedom. > But realtimeness causes problems: there is still a 512 sample delay > at the output (but not between the orig and conv signals!) which causes > that changes in convolution module parameters (if any) is heard > after 512 samples. Right? I think youi correct trying to use FFT with a 1-by-1 scheme will introduce delays. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sat Aug 1 16:33:01 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id QAA24992 for ; Sat, 1 Aug 1998 16:33:00 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106105-13530>; Sat, 1 Aug 1998 16:33:52 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@alpha.tat.physik.uni-tuebingen.de In-reply-to: (message from P J Leonard on Sat, 1 Aug 1998 09:40:13 +0100 (BST)) Subject: Re: KSynth feedback Message-Id: <19980801143331Z1576-15808+3171@nic.funet.fi> Date: Sat, 1 Aug 1998 17:33:28 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"ab6pbfqVMTO.A.DVE.Qdyw1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/26 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sat, 1 Aug 1998 16:33:52 +0200 Status: O Content-Length: 469 Lines: 16 >From: P J Leonard > >> But realtimeness causes problems: there is still a 512 sample delay >> at the output (but not between the orig and conv signals!) which causes >> that changes in convolution module parameters (if any) is heard >> after 512 samples. Right? > > I think youi correct trying to use FFT with a 1-by-1 scheme will >introduce delays. Sorry, I don't understand your writing. Would you please explane more carefully? Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Aug 2 20:36:18 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA27296 for ; Sun, 2 Aug 1998 20:36:16 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106274-211>; Sun, 2 Aug 1998 20:37:10 +0200 Date: Sun, 2 Aug 1998 19:36:44 +0100 (BST) From: P J Leonard To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: KSynth feedback In-Reply-To: <19980801143331Z1576-15808+3171@nic.funet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"JPaunvcI5fN.A.6XB.WHLx1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/27 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 2 Aug 1998 20:37:10 +0200 Status: O Content-Length: 1556 Lines: 41 On Sat, 1 Aug 1998, Juhana K Kouhia wrote: > >From: P J Leonard > > > >> But realtimeness causes problems: there is still a 512 sample delay > >> at the output (but not between the orig and conv signals!) which causes > >> that changes in convolution module parameters (if any) is heard > >> after 512 samples. Right? > > > > I think youi correct trying to use FFT with a 1-by-1 scheme will > >introduce delays. > > Sorry, I don't understand your writing. Would you please explane more > carefully? Hello, It is probably my fault for typing very quickly and not reading your mail properly. I thought that you were stating that it is not possible to do a convolution or FFT without introducing delays. Thus making it difficult to use such things for real time processing (although 512 samples at 22kHz is only about a 1/20th of second so it is probably not too bad. However if you attempt to put many such effects in series it might start to be unacceptable. On another topic that might be of interest to you . . . I have (well a student of mine) has been looking using LPC analysis as an alternative to a FFT. You can get some interesting vocoder type effects by using the LPC filter coeffiecents with another source. For example you can make a violin quartet speak :-) Have you considered using LPC as a means of synthesis (really just a high order filter which can have it's feed back coeffiecents tweaked. It would be quite quick for play back and it is quite a good model of what goes on in reality. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Aug 3 00:32:47 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id AAA28167 for ; Mon, 3 Aug 1998 00:32:45 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106648-11677>; Mon, 3 Aug 1998 00:32:51 +0200 Message-ID: <19980802224711.57803@space.twc.de> Date: Sun, 2 Aug 1998 22:47:11 +0200 From: Stefan Westerfeld To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Design issues References: <19980727184437.24087@space.twc.de> <35BD98CA.167E@bath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <35BD98CA.167E@bath.ac.uk>; from P.J.Leonard on Tue, Jul 28, 1998 at 10:24:26AM +0100 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"WflOA0Lm8pF.A.knF.SkOx1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/28 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 3 Aug 1998 00:32:51 +0200 Status: O Content-Length: 8616 Lines: 232 Hi! On Tue, Jul 28, 1998 at 10:24:26AM +0100, P.J.Leonard wrote: > > Currently, KSynth only uses one major class/type: synthesis modules. They > > get all data as floats, and output it as floats. The floats are directly > > conencted via pointers. (E.g. the out[2] pointer of synthesis module #1 > > points to the same float as the in[1] pointer of synthesis module #2, > > making a connection between). > > I would recommend doubles. floats will suffer from round off during > processing. I will do that soon. KWave has a define for this as well (MY_FLOAT), so you can decide whether to use floats or doubles when you compile. I am not sure how the performance compares on all that configurations out there, so leaving this configurable should be the best solution. > > One can say that this one class was non visual. > > > > What I propose is to provide 5 classes in the future: > > > > - types > > - interfaces > > - synthesis modules > > - editors > visual > > - viewers > visual > > > > Explaining these: > > > > 1. types > > > > Types would be what floats are now: the way you connect modules. The > > elegant thing is, that since types are no longer limited to floats, you > > could specify anything you like as a type, for instance a float, or > > a FastTracker-Envelope, or a midi event, or a sample form, or a sequence, > > that contains multiple notes, such as A-4;C-4;D-4;E-4;. > > This means a module is going to do it's own sequencing ? I would keep > the sequencing > seperate from the sound production module. No, I would prefer if everything would use the midibus stuff in the future. It was just an example what you could do with the "types"-stuff, if you wanted to. > > Every type should provide > > > > - a save to stream, load from stream function > > - a name for finding/using it > > An integer handle and a type ? When the type is initialized, one should have access to it using a Corba reference. For the programmer, this would look like an ordinary object. A name should only be provided in order to be able to specify for instance that a module has THIS type as input channel. E.g. you have a type "Midi_Event", you should specify that a Synth_NOTE-object as a channel for "Midi_Event"s. The types should be registered somehow so that ksynth can say "create me an instance of a Midi_Event". > > - a constructor/destructor > > - the necessary interface to access its data > > - possible a way to access its data directly without interface functions > > (such as accessing a float again via pointer, saving the performance > > impact using getValue or setValue functions) > > Presumably the GUI does not need to be that effecient ? This is all > wrapped > up in CORBA ? Do your synth components talk via CORBA as well ? If so > it is going > to be very slooowwww ? The synth components (the non visual synthesis modules) don't talk via CORBA, because of the speed. The communication between a slider where you can regulate the frequency and the synthesizer core shouldn't be time critical. I have done some tests today, the code should be in the CVS as you read this - just a hack though. We talk about rates of one update per 1000 samples. > > Connections would be typed, allowing you to connect a module that generates > > an FastTracker-Envelope to one that uses one to scale its waves. > > > > 2. interfaces > > > > Interfaces would specify a name, and which ports they have. > > > > Ports should have information about their name, how they are typed, and > > what directory they go. > > > > example for a delay interface > > > > port #1: in signal, type float > > port #2: in time, type float > > port #3: out signal, type float > > > > example for a fasttracker style envelope scaler > > > > port #1: in midi, type midievent > > port #2: in envelope, type fasttracker_envelope > > port #3: in signal, type float > > port #4: out signal, type float > > DO these live in a ksynth description file ? Not yet at least ;) > e.g. > ---- component descriptions > > module: piano > port #1: in midi, type midi > port #2: out signal, type float > > module: reverb > port #1: in depth,type double, range 0-100, unit percent > > note the addition of range and unit for the GUI to feed off. Component description currently only exist in the source (synth_server), and are queryable via CORBA. Writing a program that dumps the textfile as you described it should be no problem. Adding ranges of values a module accepts is an idea we surely could need. We have discussed before that gain considerations are important. > ---- instrument descriptions > > The job of the GUI is to build a connection matix from these components. > This could be in the form > > instrument: honky-tonk : piano,chorus % define instument and it's > components > instrument:midi -> piano:midi % midi in events go to the > piano > chorus:out -> instrument:out % take signal out from > chorus out > instrument:filter[midi-in CNTRL CHORUS]:out -> chorus:depth % route a > midi effect to the chorus depth > piano:out -> chorus->in % feed piano into the > chorus Thats about it. What I am missing here is the seperation between interface and implementation. I would like to have something like interface: instrument port #1: in midi, type midi port #2: out signal, type float module: piano implements instrument; instrument:midi -> piano:midi % not sure whether this is necessary piano:out -> instrument:out % perhaps leave these two lines away module: honky-tonk implements instrument; contains piano, chorus; instrument:midi -> piano:midi chorus:out -> instrument:out instrument:filter[midi-in CNTRL CHORUS]:out -> chorus:depth piano:out -> chorus:in Then, you can build structures which contain instruments, which are filled later with the concrete instruments (e.g. filled with a piano or honky-tonk or whatever). > Note an instument could also be used as a component. > > > --- > > Finally we have a patch file that associates midi program-bank pairs > with instruments. > > 0:0 honk-tonk > 0:1 wierd-piano I would like to have that behaviour not be the default for every ksynth, but achieved by a structure (synthesis module), and by some of ksynths components. > Now the users of say cantor can load instruments into the synth module > using program-bank pairs. Yes, that's the way it should be. By the way, what exactly is the strategy there? Do you get bank switches and program changes? And will KSynth need to be present on different midi channels for that to work with different instruments playing simultaneously? We haven't implemented program/bank-switching in the midibus yet. > > Interfaces should be independant of their implementations, while > > implentations can either be single modules or structures of modules. > > > > 3. modules > > > > A module should > > > > - implement an interface > > - have a name > > - have a start/stop function for initialization and deinitialization > > - have a calculation function for the actual calculation > > > > 4. editors > > > > An editor is a visual control that edits elements of a certain type. For > > one type may exist multiple editors, such as for a float a simple text > > field or a scroll bar. > > > > Editors should be the only interface from the user to the synthesis module > > when specifying values or modifying them (such as specifying the length > > of a delay or the envelope an instrument should use for scaling). > > Do modules need to inform any interested parties (viewers) > that they have been modified ? Yes, thats what I think they should do. I am not sure whether we need to differentiate between things that change fast (e.g. the signal) and things that change slow (e.g. the echo depth that a user can modify with a button on the screen). Another thing that is interesting is the amount of things that KOM/OpenParts and similar stuff could do for us when we use it, and the amount of things we need to reimplement (e.g. due to portability or performance problems). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Aug 3 00:39:31 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id AAA28175 for ; Mon, 3 Aug 1998 00:39:30 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106183-23394>; Mon, 3 Aug 1998 00:40:05 +0200 Message-ID: <19980801145641.51921@space.twc.de> Date: Sat, 1 Aug 1998 14:56:41 +0200 From: Stefan Westerfeld To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Mico compile problem References: <199807310935.LAA08574@giger.iamexwi.unibe.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199807310935.LAA08574@giger.iamexwi.unibe.ch>; from the Physicist on Fri, Jul 31, 1998 at 11:35:14AM +0200 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"84lUAbZ2UpP.A.ewF.FrOx1"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/29 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 3 Aug 1998 00:40:05 +0200 Status: O Content-Length: 1386 Lines: 35 Hi! On Fri, Jul 31, 1998 at 11:35:14AM +0200, the Physicist wrote: > Yesterday I tried to compile ksynth for first experiments. > So I first wanted to compile mico-2.1.1. > As proposed on the mico-pages, I have gcc-2.7.2 (actually gcc-2.7.2.3) > and libg++-2.7.2.8 > All the same, I get the following error while compiling: > > c++ -I. -I../include -I/usr/local/src/KDE/mico/./include/ministl -O -I/usr/local/include -c dii.cc -o dii.o > In file included from ../include/CORBA.h:92, > from dii.cc:23: > ../include/mico/sequence.h:269: Internal compiler error. > ../include/mico/sequence.h:269: Please submit a full bug report to `bug-g++@prep.ai.mit.edu'. > > What am I doing wrong ? It's not your fault. You have found a compiler bug. Most gccs, including egcs (though it's a lot better there), crash when compiling some C++ constructs. You can try to - compile this file without optimizer - add an empty destructor to the class where it crashes, if the class had no destructor before - contact the mico-people via their mailing-list If you want to have something that works better, invest the time and upgrade to egcs. It might be a little difficult, but its definitely worth the time. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Aug 11 10:30:21 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA22791 for ; Tue, 11 Aug 1998 10:30:20 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106516-9829>; Tue, 11 Aug 1998 10:31:42 +0200 Sender: pjl@bath.ac.uk Message-ID: <35D0019F.3F54@bath.ac.uk> Date: Tue, 11 Aug 1998 09:32:31 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Design issues References: <19980727184437.24087@space.twc.de> <35BD98CA.167E@bath.ac.uk> <19980802224711.57803@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"__edcDRCKqI.A.93C.uFA01"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/30 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 11 Aug 1998 10:31:42 +0200 Status: O Content-Length: 1716 Lines: 54 Stefan Westerfeld wrote: > I would like to have that behaviour not be the default for every ksynth, > but achieved by a structure (synthesis module), and by some of ksynths > components. > > > Now the users of say cantor can load instruments into the synth module > > using program-bank pairs. > > Yes, that's the way it should be. > > By the way, what exactly is the strategy there? Do you get bank switches > and program changes? As far as cantor is concerned it sees midi-devices. A device gets sent events event { int device int chan enum event_type // e.g. midi types data data // actual info. } Bank switches and program changes are an event types with data. > And will KSynth need to be present on different midi channels for that > to work with different instruments playing simultaneously? Yes. > We haven't implemented program/bank-switching in the midibus yet. Prehaps we could just send the events over the midi-bus to the ksynth device and sort things out at the server end ? If you want to do this I will tidy up my event types. > > Do modules need to inform any interested parties (viewers) > > that they have been modified ? > > Yes, thats what I think they should do. I am not sure whether we need to > differentiate between things that change fast (e.g. the signal) and things > that change slow (e.g. the echo depth that a user can modify with a button > on the screen). > > Another thing that is interesting is the amount of things that KOM/OpenParts > and similar stuff could do for us when we use it, and the amount of things > we need to reimplement (e.g. due to portability or performance problems).  KOM/OpenParts ? What is this ? cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Aug 16 23:08:39 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA11050 for ; Sun, 16 Aug 1998 23:08:38 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106160-28257>; Sun, 16 Aug 1998 23:09:47 +0200 Message-ID: <19980816230745.43936@space.twc.de> Date: Sun, 16 Aug 1998 23:07:45 +0200 From: Stefan Westerfeld To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Design issues References: <19980727184437.24087@space.twc.de> <35BD98CA.167E@bath.ac.uk> <19980802224711.57803@space.twc.de> <35D0019F.3F54@bath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <35D0019F.3F54@bath.ac.uk>; from P.J.Leonard on Tue, Aug 11, 1998 at 09:32:31AM +0100 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"iBM1eVWLDBL.A.r3D.bq011"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/31 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 16 Aug 1998 23:09:47 +0200 Status: O Content-Length: 3380 Lines: 90 Hi! On Tue, Aug 11, 1998 at 09:32:31AM +0100, P.J.Leonard wrote: > > I would like to have that behaviour not be the default for every ksynth, > > but achieved by a structure (synthesis module), and by some of ksynths > > components. > > > > > Now the users of say cantor can load instruments into the synth module > > > using program-bank pairs. > > > > Yes, that's the way it should be. > > > > By the way, what exactly is the strategy there? Do you get bank switches > > and program changes? > > As far as cantor is concerned it sees midi-devices. A device gets sent > events > > event { > int device > int chan > enum event_type // e.g. midi types > data data // actual info. > } > > > Bank switches and program changes are an event types with data. > > > And will KSynth need to be present on different midi channels for that > > to work with different instruments playing simultaneously? > > Yes. > > > We haven't implemented program/bank-switching in the midibus yet. > > Prehaps we could just send the events over the midi-bus to the ksynth > device and sort things out at the server end ? If you want to do this > I will tidy up my event types. This would have the advantage that the midibus interface remains small, and as well contains about everything that midi can ever do. The question that perhaps could help us to find a good midibus interface is: What would a midibus interface be required to have, until you can throw every code related to playing midi on several devices out of Cantor, and implement is as midibus target objects? The interface should feature the querying about capabilities that you eventually to with Cantor as well. > > > Do modules need to inform any interested parties (viewers) > > > that they have been modified ? > > > > Yes, thats what I think they should do. I am not sure whether we need to > > differentiate between things that change fast (e.g. the signal) and things > > that change slow (e.g. the echo depth that a user can modify with a button > > on the screen). > > > > Another thing that is interesting is the amount of things that KOM/OpenParts > > and similar stuff could do for us when we use it, and the amount of things > > we need to reimplement (e.g. due to portability or performance problems). > > KOM/OpenParts ? What is this ? KOM/OpenParts is what KOffice uses to do all it's magic ;) Look at: - http://www-chaos.umd.edu/~dsweet/KDE/KTrans - http://www.kde.org/whatiskde/openparts.html - http://www.kde.org/whatiskde/koffice.html Basically, what it could do for us is handling embedded controls. Such as viewers that show the level of a signal, or oscilloscope controls or buttons or whatever. I would like to have them embeddable, so that they are the elements you built the GUI of the synthesizer module from. That means if you are creating something like an effect panel, you can create the graphic design using these controls. This would make it possible to port KSynth to Gnome for instance, while keeping the visual appearance of the plugins (which of course would remain Qt based, what means they would need to be compilable with Harmony, in order to be acceptable for Qt license haters). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Aug 16 23:27:38 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA11073 for ; Sun, 16 Aug 1998 23:27:37 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106192-28257>; Sun, 16 Aug 1998 23:28:40 +0200 Message-ID: <19980816232610.34340@space.twc.de> Date: Sun, 16 Aug 1998 23:26:10 +0200 From: Stefan Westerfeld To: ksynth@kde.org Subject: Delay trouble Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"J1jNh4lzqO.A.yUE.I8011"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/32 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 16 Aug 1998 23:28:40 +0200 Status: O Content-Length: 1546 Lines: 43 Hi! I have put some code into KSynth, that let's the user modify certain values at runtime, such as the delay of a Synth_DELAY module. Now, this is the structure of a "parametrized echo effect": +------------+ | V input --->+-delay->--mixing---> output ^ | parameter: time The delay module simply takes the input stream (back)buffers it. It outputs the values it has seen on its input the given time before. The original stream and the delayed stream are mixed "down the line", and you get an output signal. Now the problem I have is: - When the parameter time changes slowly, but every single value is different (no jumps, just continous change), I get a "Dopplereffect", that means the frequency of the signal changes, since the waves are compressed or stretched. - When the parameter time changes in steps, like you get when you have a user that modifies a scrollbar (the scrollbar gives you 50 values at best, over a time of perhaps half a second the user needs to make his modification), I get clicks. This happens, since the delay modules output value is the input value it has seen perhaps 0.1 seconds ago. Then, from one sample to another it is the input value it has seen 0.13 seconds ago. These signals are not likely to fit together. What can I do to solve this reasonable? Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Aug 17 10:39:29 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA12033 for ; Mon, 17 Aug 1998 10:39:28 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106113-15666>; Mon, 17 Aug 1998 10:41:02 +0200 Sender: pjl@bath.ac.uk Message-ID: <35D7EC2E.41C6@bath.ac.uk> Date: Mon, 17 Aug 1998 09:39:11 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Design issues References: <19980727184437.24087@space.twc.de> <35BD98CA.167E@bath.ac.uk> <19980802224711.57803@space.twc.de> <35D0019F.3F54@bath.ac.uk> <19980816230745.43936@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"bzmJ5GEJ_P.A.ab.ey-11"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/33 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 17 Aug 1998 10:41:02 +0200 Status: O Content-Length: 3033 Lines: 80 Stefan Westerfeld wrote: [snip] > This would have the advantage that the midibus interface remains small, > and as well contains about everything that midi can ever do. > > The question that perhaps could help us to find a good midibus interface > is: > > What would a midibus interface be required to have, until you can throw > every code related to playing midi on several devices out of Cantor, > and implement is as midibus target objects? Sorry I did not quite understand the above. Are we trying to define a generic message passing interface such that cantor need not contain any device specific code ? > The interface should feature the querying about capabilities that you > eventually to with Cantor as well. As far as cantor core itself is concerned it just needs to to see devices that can handle midi events. What patches are loaded into these devices can be handled by other programs providing the devices allow some sort of sharing. It would be nice if the device could provide a list of patches program / bank: patch name Cantor would like to see a list of the avialable effects that are avialable on a given device/channel. This would require the device to supply a list of messages in the form MidiEvent:name:unit:range The above should not be compulsary but would be nice for the GUI. Unless you like working with integers all the time :-) > > > > Do modules need to inform any interested parties (viewers) > > > > that they have been modified ? > > > > > > Yes, thats what I think they should do. I am not sure whether we need to > > > differentiate between things that change fast (e.g. the signal) and things > > > that change slow (e.g. the echo depth that a user can modify with a button > > > on the screen). > > > > > > Another thing that is interesting is the amount of things that KOM/OpenParts > > > and similar stuff could do for us when we use it, and the amount of things > > > we need to reimplement (e.g. due to portability or performance problems). > > > > KOM/OpenParts ? What is this ? > > KOM/OpenParts is what KOffice uses to do all it's magic ;) Look at: > > - http://www-chaos.umd.edu/~dsweet/KDE/KTrans > - http://www.kde.org/whatiskde/openparts.html > - http://www.kde.org/whatiskde/koffice.html > > Basically, what it could do for us is handling embedded controls. Such as > viewers that show the level of a signal, or oscilloscope controls or > buttons or whatever. > > I would like to have them embeddable, so that they are the elements you > built the GUI of the synthesizer module from. That means if you are > creating something like an effect panel, you can create the graphic design > using these controls. > > This would make it possible to port KSynth to Gnome for instance, while > keeping the visual appearance of the plugins (which of course would remain > Qt based, what means they would need to be compilable with Harmony, in > order to be acceptable for Qt license haters). Sounds cool I will take a peek if I have time :-) cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Aug 18 13:21:48 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id NAA14717 for ; Tue, 18 Aug 1998 13:21:47 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106661-4936>; Tue, 18 Aug 1998 13:22:59 +0200 Sender: pjl@bath.ac.uk Message-ID: <35D9637E.446B@bath.ac.uk> Date: Tue, 18 Aug 1998 12:20:30 +0100 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Delay trouble References: <19980816232610.34340@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"XFsoQAERATG.A.k4B.TQW21"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/34 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 18 Aug 1998 13:22:59 +0200 Status: O Content-Length: 1988 Lines: 54 Stefan Westerfeld wrote: > > Hi! > > I have put some code into KSynth, that let's the user modify certain > values at runtime, such as the delay of a Synth_DELAY module. > > Now, this is the structure of a "parametrized echo effect": > > +------------+ > | V > input --->+-delay->--mixing---> output > ^ > | > parameter: > time > > The delay module simply takes the input stream (back)buffers it. It outputs > the values it has seen on its input the given time before. The original > stream and the delayed stream are mixed "down the line", and you get an > output signal. > > Now the problem I have is: > > - When the parameter time changes slowly, but every single value is > different (no jumps, just continous change), I get a > "Dopplereffect", that means the frequency of the signal changes, > since the waves are compressed or stretched. Cool!!! are you interpolating to get the delayed version ? > > - When the parameter time changes in steps, like you get when you > have a user that modifies a scrollbar (the scrollbar gives you > 50 values at best, over a time of perhaps half a second the > user needs to make his modification), I get clicks. > > This happens, since the delay modules output value is the input value > it has seen perhaps 0.1 seconds ago. Then, from one sample to another > it is the input value it has seen 0.13 seconds ago. These signals > are not likely to fit together. > > What can I do to solve this reasonable?  What do you want the desired effect to be ? The above sounds like it is behaving exactly as it should behave :-) If you wish to ensure that you have not got any glitches then you should not modify the delay in a step wise fashion. Sorry I can not be more help but this looks like the right answer but the wrong question. cheers Paul. From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sat Sep 26 19:39:36 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA07014 for ; Sat, 26 Sep 1998 19:39:35 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106435-30904>; Sat, 26 Sep 1998 19:41:42 +0200 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: audiotechque@fmc-container.mach.uni-karlsruhe.de, ksynth@alpha.tat.physik.uni-tuebingen.de Subject: OPDSP Message-Id: <19980926174042Z19582-11335+2156@nic.funet.fi> Date: Sat, 26 Sep 1998 20:40:41 +0300 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"a2ScPoTIB2D.A.sEE.WdSD2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/35 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sat, 26 Sep 1998 19:41:42 +0200 Status: O Content-Length: 339 Lines: 9 Yet another audio flow program: opdsp. This is from 1995 but somehow I have missed it. Look at "http://www.mtnmath.com/". The documentation mentions a research paper on the flow systems. Proc. IEEE, vol. 75, no. 9, Sept 1987. (For example SAOL's flow system is made intuitively and author has no references on audio flow.) Yours, Juhana From majordom@fmc-container.mach.uni-karlsruhe.de Sat Sep 26 20:03:27 1998 Received: from fmc-container.mach.uni-karlsruhe.de (mail@fmc-container.mach.uni-karlsruhe.de [129.13.112.111]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA07068 for ; Sat, 26 Sep 1998 20:03:26 +0200 Received: from majordom by fmc-container.mach.uni-karlsruhe.de with local (Exim 1.92 #1) id 0zMyL2-0001Dz-00 (Debian); Sat, 26 Sep 1998 19:40:56 +0200 Received: from (nic.funet.fi) [128.214.248.6] by fmc-container.mach.uni-karlsruhe.de with esmtp (Exim 1.92 #1) id 0zMyL0-0001Dt-00 (Debian); Sat, 26 Sep 1998 19:40:54 +0200 Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <19582-11335>; Sat, 26 Sep 1998 20:40:41 +0300 From: Juhana K Kouhia To: audiotechque@fmc-container.mach.uni-karlsruhe.de, ksynth@alpha.tat.physik.uni-tuebingen.de Subject: [atech] OPDSP Message-Id: <19980926174042Z19582-11335+2156@nic.funet.fi> Date: Sat, 26 Sep 1998 20:40:41 +0300 Precedence: bulk Reply-To: audiotechque@fmc-container.mach.uni-karlsruhe.de Sender: majordom Status: O Content-Length: 339 Lines: 9 Yet another audio flow program: opdsp. This is from 1995 but somehow I have missed it. Look at "http://www.mtnmath.com/". The documentation mentions a research paper on the flow systems. Proc. IEEE, vol. 75, no. 9, Sept 1987. (For example SAOL's flow system is made intuitively and author has no references on audio flow.) Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Oct 25 00:21:00 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id AAA11498 for ; Sun, 25 Oct 1998 00:21:00 +0200 Received: by alpha.tat.physik.uni-tuebingen.de id <106084-180>; Sun, 25 Oct 1998 00:21:29 +0200 From: Volker Assmann To: ksynth@kde.org Subject: subscribe volka@bigfoot.de Date: Sun, 25 Oct 1998 00:18:22 +0200 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain; charset=US-ASCII MIME-Version: 1.0 Message-Id: <98102500185202.00491@Brain> Content-Transfer-Encoding: 7BIT Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"wDJvQJLLb0J.A.ky.pLlM2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/36 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Sun, 25 Oct 1998 00:21:29 +0200 Status: O Content-Length: 268 Lines: 8 -----BEGIN PGP MESSAGE----- Version: 2.6.3i owEBhQB6/4kAdQMFADYyUk8oXKDgCowq8QEB8q4DAMRxgvdr1zUXR4bI4BDEsRWW bLKYg7hEu3uwAizJu46z+R0Q07LWHpckteep8UnezL0VrEaxsur+/fIro/dVCLqD VmDblDG5SQKIfJ1C5o16MEkbZY68HoryCjc4nPINZqwLYgVzdGRpbgAAAAA= =c45B -----END PGP MESSAGE----- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Nov 2 19:18:33 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA28836 for ; Mon, 2 Nov 1998 19:18:32 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106209-5856>; Mon, 2 Nov 1998 19:19:04 +0100 Date: Mon, 2 Nov 1998 19:17:22 +0100 (MEZ) From: Harald Lapp X-Sender: aurora@inn.awi.fh-rosenheim.de To: ksynth@kde.org Subject: controller... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"XVSQdxFnZAK.A.DHD.YefP2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/37 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 2 Nov 1998 19:19:04 +0100 Status: O Content-Length: 685 Lines: 20 hi! i just read the 'midibus'-readme file yesterday again,... there are some nice tools for win95, wheere you can use anormal joystick as midicontroller.. (the tool converts the joystick-data into midi-data). as i built a little faderbox (4 potis) for the joystick-port to control some win95-music-soft a while ago, i thought it would be nice, to use this little box under linux, too :-).., maybe there already exists a tool for linux which does the same as the win95-tools? or does someone like to code it? :-).... or do i have to code it on my own?? ;-(... i thought i've to use the midi-bus then? ... any ideas? bye! <-harald p.s.: we've a new site for the webpages, soon :-) From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Nov 3 14:20:20 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id OAA30796 for ; Tue, 3 Nov 1998 14:20:19 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106192-233>; Tue, 3 Nov 1998 14:21:18 +0100 Sender: kouhia@nic.funet.fi From: Juhana K Kouhia To: ksynth@alpha.tat.physik.uni-tuebingen.de CC: ksynth@kde.org In-reply-to: (message from Harald Lapp on Mon, 2 Nov 1998 19:17:22 +0100 (MEZ)) Subject: Re: controller... Message-Id: <19981103132053Z20131-9020+151@nic.funet.fi> Date: Tue, 3 Nov 1998 15:20:48 +0200 Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"yqXHGRBSYtN.A.Ma.ONwP2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/38 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Tue, 3 Nov 1998 14:21:18 +0100 Status: O Content-Length: 2124 Lines: 41 Are those two different ksynth mailing list the same or not? If yes, please remove one of them if you reply. >as i built a little faderbox (4 potis) for the joystick-port to >control some win95-music-soft a while ago, i thought it would be >nice, to use this little box under linux, too :-).., Sounds great. I would like to have the building instructions if you don't mind. I'm also interested in to design a control box meant for live performances (say) but such a box also needs a simple sequencer part which controls the KSynth. The basic idea in my current design is that when you press a button on the control box, you get a sound. Some buttons may have one sound but some buttons may have a complete sequence. Some buttons may be programmed to wait until some sound is finished and only after then the sound belonging to the button is started. My first Linux program was that kind of sequencer: by pressing keys of keyboard samples or sequences were played, one button switched between looping and no looping modes. To me it is not that clear how MIDI box such as above could work in KSynth. Has Linux a MIDI device cabable of reading the faderbox? How MIDI events are read from the device? Should there be a separate process or thread which just waits for MIDI events? I remember select() is a routine which halts the process until something is in the device. Please look at "http://www.modeemi.cs.tut.fi/~jams/flow/" for signal flow system. It is meant to be in Audiotechque. KSynth's flow system process one sample at a time but the above flow system process N samples at a time. In my opinion, both are equally good and bad. I'm working on a flow system which is optimally fast or such but I have some difficulties --- perhaps I should put all my notes available in case some of you could come up with new ideas which solves my problems? Also, look at www.creamware.de, at their news section and article "...introduce the Pulsar" (or such). Click the image representing the module system to get the full size screenshot visible. It is a cute alternative for the rectangle plus lines approach. Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Dec 18 05:11:53 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id FAA00858 for ; Fri, 18 Dec 1998 05:11:52 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106133-9579>; Fri, 18 Dec 1998 05:14:16 +0100 Sender: crump@cybercom.net Message-ID: <3679D6A9.6EC4AC31@cybercom.net> Date: Thu, 17 Dec 1998 23:14:33 -0500 From: David Crump X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ksynth@kde.org Subject: Question about cantor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"954Ebo9kVLD.A.WR.Yade2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/39 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 18 Dec 1998 05:14:16 +0100 Status: O Content-Length: 497 Lines: 16 I'm not exactly sure what cantor is or where I can find it. Apparently I need it to run an example in Ksynth. I have successfully compiled and installed Mico and Ksynth, and read the README for Ksynth. It says to "take a version of cantor with midi bus suport...and compile." What exactly does this do for me? Will I essentially be able to 'stream' a midi file in Ksynth so I can manipulate it and save it as a wav file? Any pointers to info would be helpful. Thanks, dave crump@cybercom.net From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Dec 18 05:22:34 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id FAA00866 for ; Fri, 18 Dec 1998 05:22:33 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106111-9579>; Fri, 18 Dec 1998 05:25:06 +0100 Sender: crump@cybercom.net Message-ID: <3679D926.8D04D472@cybercom.net> Date: Thu, 17 Dec 1998 23:25:10 -0500 From: David Crump X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) MIME-Version: 1.0 To: ksynth@kde.org Subject: Question about cantor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"TwKolcEiyiF.A.PU.ikde2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/40 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 18 Dec 1998 05:25:06 +0100 Status: O Content-Length: 497 Lines: 16 I'm not exactly sure what cantor is or where I can find it. Apparently I need it to run an example in Ksynth. I have successfully compiled and installed Mico and Ksynth, and read the README for Ksynth. It says to "take a version of cantor with midi bus suport...and compile." What exactly does this do for me? Will I essentially be able to 'stream' a midi file in Ksynth so I can manipulate it and save it as a wav file? Any pointers to info would be helpful. Thanks, dave crump@cybercom.net From ksynth-request@alpha.tat.physik.uni-tuebingen.de Fri Dec 18 10:03:34 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA01198 for ; Fri, 18 Dec 1998 10:03:32 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106133-5193>; Fri, 18 Dec 1998 10:06:06 +0100 Sender: pjl@bath.ac.uk Message-ID: <367A1A8F.167E@bath.ac.uk> Date: Fri, 18 Dec 1998 09:04:15 +0000 From: "P.J.Leonard" Organization: Applied Electromagnetic Research Centre X-Mailer: Mozilla 3.0 (X11; I; OSF1 V2.0 alpha) MIME-Version: 1.0 To: ksynth@alpha.tat.physik.uni-tuebingen.de Subject: Re: Question about cantor References: <3679D926.8D04D472@cybercom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Old-Return-Path: X-Orcpt: rfc822;ksynth@alpha.tat.physik.uni-tuebingen.de Resent-Message-ID: <"fRnhJsv1t8K.A.iWD.-rhe2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/41 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Fri, 18 Dec 1998 10:06:06 +0100 Status: O Content-Length: 1437 Lines: 49 David Crump wrote: > > I'm not exactly sure what cantor is or where I can find it. > > Apparently I need it to run an example in Ksynth. I have successfully > compiled and installed Mico and Ksynth, and read the README for Ksynth. > > It says to "take a version of cantor with midi bus suport...and > compile." > > What exactly does this do for me? Will I essentially be able to 'stream' > a midi file in Ksynth so I can manipulate it and save it as a wav file? Cantor will allow you to. 1. Read in a midi file and it will send midi events to ksynth via the midi bus. > Any pointers to info would be helpful. Cantor can be found at ftp://ftp.bath.ac.uk/pub/eespjl/cantor/ I hope to put the latest version (all the latest bugs) on the site on monday so you may want to wait. -- Cheers Paul. __ __ ( ) _ - _ ( ) ~~ ~~ ( 0 0 ) ----------ooO----( )----Ooo------------ ''' ( ) ''' ( ) \ / ~~O~~ Tel: +44 1225 826108 Fax: +44 1225 826305 snail: P.J.Leonard Applied Electromagnetic Research Centre Bath University, BATH, UK BA2 7AY From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Dec 28 21:40:50 1998 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id VAA21971 for ; Mon, 28 Dec 1998 21:40:48 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106397-24100>; Mon, 28 Dec 1998 21:43:17 +0100 From: Stefan Westerfeld Message-Id: <199812282039.VAA21956@space.twc.de> Subject: Re: Synthesizer To: ujas@rz.uni-karlsruhe.de (Tobi) Date: Mon, 28 Dec 1998 21:39:30 +0100 (CET) Cc: ksynth@kde.org In-Reply-To: <367E254F.7F838F57@rz.uni-karlsruhe.de> from "Tobi" at Dec 21, 98 11:39:11 am Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"W_eN7SIezXF.A.8OG.i1-h2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/42 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Mon, 28 Dec 1998 21:43:17 +0100 Status: O Content-Length: 4077 Lines: 87 Hi! > eigentlich wollte ich nur schnell Deinen Synthesizer ausprobieren. > Dies artete dann aber in eine 10 stündige Sitzung "Compiler compilieren" > aus. > Mit egcs Version 1.1.1 tritt jetzt aber immer noch folgende > Fehlermeldung auf: (small translation: compiling ksynth with egcs 1.1.1 results in the following error messages:) > --------------403A10BA8CA77BC28D3D4881 > Content-Type: text/plain; charset=us-ascii; name="Error" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; filename="Error" > > make all-recursive > make[1]: Entering directory /opt/ksynth' > Making all in src > make[2]: Entering directory /opt/ksynth/src' > Making all in synthesizer > make[3]: Entering directory /opt/ksynth/src/synthesizer' > /bin/sh ../../libtool --mode=link g++ -O2 -Wall -L/opt/kde/lib > -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth_server.o > synth_impl.o synth.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o > midibus.o midisupport.o -lmico2.2.3 -ldl > g++ -O2 -Wall -L/opt/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o > synth_server.bin synth_server.o synth_impl.o synth.o synthmodule.o ioevent.o > modules.o sound-linux.o utils.o midibus.o midisupport.o -lmico2.2.3 -ldl > synth.o: In function Synthesizer_skel type_info function': > synth.o(.text+0x32f0): undefined reference to ORBA::MethodDispatcher > type_info function' > synth.o: In function Synthesizer type_info function': > synth.o(.text+0x33d3): undefined reference to ORBA::Object type_info > function' > synth.o(.rodata+0x494): undefined reference to ORBA::MethodDispatcher > type_info node' > synth.o(.rodata+0x4d4): undefined reference to ORBA::Object type_info node' > synth.o: In function nterfaceDispatcherWrapper > type_info function': > synth.o(.gnu.linkonce.t.__tft26InterfaceDispatcherWrapper1Z17KSynthesizer_skel+0x13): > undefined reference to ORBA::InterfaceDispatcher type_info function' > synth.o(.gnu.linkonce.t.__tft26InterfaceDispatcherWrapper1Z17KSynthesizer_skel+0x18): > undefined reference to ORBA::InterfaceDispatcher type_info node' > ioevent.o: In function SynthIOEvent type_info function': > ioevent.o(.text+0x207): undefined reference to ORBA::DispatcherCallback > type_info function' > ioevent.o(.text+0x20c): undefined reference to ORBA::DispatcherCallback > type_info node' > midibus.o: In function > idiChannel_skel type_info function': > midibus.o(.text+0x1404): undefined reference to ORBA::MethodDispatcher > type_info function' > midibus.o: In function > idiChannel type_info function': > midibus.o(.text+0x14e7): undefined reference to ORBA::Object type_info > function' > midibus.o(.rodata+0x294): undefined reference to ORBA::MethodDispatcher > type_info node' > midibus.o(.rodata+0x2d4): undefined reference to ORBA::Object type_info > node' > midibus.o: In function nterfaceDispatcherWrapper > type_info function': > midibus.o(.gnu.linkonce.t.__tft26InterfaceDispatcherWrapper1Z16MidiChannel_skel+0x13): > undefined reference to ORBA::InterfaceDispatcher type_info function' > midibus.o(.gnu.linkonce.t.__tft26InterfaceDispatcherWrapper1Z16MidiChannel_skel+0x18): > undefined reference to ORBA::InterfaceDispatcher type_info node' > collect2: ld returned 1 exit status > make[3]: *** [synth_server.bin] Error 1 > make[3]: Leaving directory /opt/ksynth/src/synthesizer' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory /opt/ksynth/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory /opt/ksynth' > make: *** [all-recursive-am] Error 2 I'll cc that to the list, so I am replying in english: The error messages look like you have parts, which have been compiled using RTTI (C++ runtime type information), and other parts which have been compiled without. You should compile everything (Qt, KDE, mico, KSynth), with the same compiler, and the same RTTI settings (either always use -fno-rtti to suppress the type information everywhere, or never use -fno-rtti and compile everything with type information). Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Wed Jan 13 19:13:53 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA31390 for ; Wed, 13 Jan 1999 19:13:52 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106108-25525>; Wed, 13 Jan 1999 19:17:23 +0100 Message-ID: <19990113191324.22753@space.twc.de> Date: Wed, 13 Jan 1999 19:13:24 +0100 From: Stefan Westerfeld To: ksynth@kde.org Subject: KSynth: 0.2.5-release Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"2S7nafr7jtB.A.LAE.zMOn2"@alpha> Resent-From: ksynth@alpha.tat.physik.uni-tuebingen.de Reply-To: ksynth@alpha.tat.physik.uni-tuebingen.de X-Mailing-List: archive/latest/43 X-Loop: ksynth@alpha.tat.physik.uni-tuebingen.de Precedence: list Resent-Sender: ksynth-request@alpha.tat.physik.uni-tuebingen.de Resent-Date: Wed, 13 Jan 1999 19:17:23 +0100 Status: RO Content-Length: 395 Lines: 12 Hi! There is a new KSynth-release (0.2.5) available. For users the new features are mainly invisible yet, but that will change with the next release. (available soon, I hope). You can get it from http://space.twc.de/~stefan/kde Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Feb 14 23:15:57 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA21177 for ; Sun, 14 Feb 1999 23:15:56 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106402-16013>; Sun, 14 Feb 1999 23:15:46 +0100 Message-ID: <19990214231523.42152@space.twc.de> Date: Sun, 14 Feb 1999 23:15:23 +0100 From: Stefan Westerfeld To: ksynth@kde.org Subject: Arts Survey Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"O2oYWjngeAJ.A.5xE.Ss0x2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/44 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Sun, 14 Feb 1999 23:15:46 +0100 Status: O Content-Length: 5443 Lines: 199 Hi! I don't know what's going on with Arts out there - I have heard of some users that had difficulties in compiling Arts, that got resolved, but I have no reports about how Arts performs in real live and what is needed. I still suppose it might be that many users simply don't understand what to do with Arts, or that Arts isn't powerful enough for real applications. This led me to the idea to put together a survey, that Arts users should fill out with every release of Arts, so that the problems and the features people desperately need become visible. I am not sure wether this is a good idea yet, or wether this will be helpful in development, but it is a try. So please fill out this survey if you are using arts-0.2.6 since some time and have gathered some experiences: Oh, and you can discuss the issue on the mailing list as well, of course. Anybody out there? Cu... Stefan ARTS SURVEY - please fill out and send to stefan@space.twc.de, subject line of the mail: ARTSSURVEY-0.2.6 ///////////////////////////////////////////////////////////////////////////// Please fill out this survey if you - are using arts-0.2.6 or a CVS snapshot which says it is arts-0.2.6 - have taken some time to play with Arts before filling out the survey These surveys will probably come with every new version of Arts. Please fill out the new survey again after you have done an upgrade of Arts, because we can then try to track the progress of Arts (and the things the users need) in the future. Please fill in your REAL OPINION, this is not right the time for making compliments: if you can't use Arts because its too slow and you fill in the performance is ok, nobody will care to make Arts faster, and you will never be able to use Arts ;) ///////////////////////////////////////////////////////////////////////////// Part I - Arts installation: =========================== * I am using - read instructions AGAIN if you have another version (pick one) [ ] arts-0.2.6 [ ] CVS snapshot of arts-0.2.6 * When compiling, I had (pick one) [ ] no success [ ] major trouble, but it works [ ] minor trouble [ ] no trouble * What trouble? * When you had trouble, please fill out this: C-Compiler : KDE-Version : Qt-Version : Mico-Version : Part II - Yourself: =================== * I have (pick many) [ ] a full duplex soundcard [ ] "real" analog synthesizers [ ] a midi keyboard [ ] a "real" mixer [ ] "real" effect processors * I am subscribed to the arts mailing-list (pick one) [ ] yes [ ] no * I have composed using these programs before (pick many) [ ] Trackers (FastTracker, IT, ScreamTracker, ...) [ ] Cubase/Calkwalk [ ] Generator [ ] Rebirth [ ] Jazz/Cantor Part III - Arts evaluation: =========================== * Arts performance is (pick one) [ ] too slow to be usable [ ] too slow [ ] acceptable [ ] good * I think I understand how I should use Arts (pick one) [ ] not at all [ ] a little [ ] quite good [ ] good [ ] perfect * What I'd like to see in the next Arts releases (pick the most important) [ ] more speed [ ] better midi effect processing (filtering midi events) [ ] interfaces to other composing software than cantor [ ] interfaces to audio editing software (such as kwave) [ ] improved midi bus [ ] GUI-Builder for having sliders and turning knobs on the screen to modify the sound settings on the fly [ ] more filters [ ] Gnome/Gtk support * The midibus standard (pick many) [ ] currently suits my needs [ ] is nice, but not complete enough for my needs [ ] is a silly idea [ ] is too slow in its implementation [ ] I don't understand how to use that anyway * I desperately need the following modules * I desperately need the following other features * The sounds I get out of Arts are (pick one) [ ] no sound [ ] only very simple [ ] simple [ ] quite nice [ ] absolutely amazing * Arts is suitable for me to produce (pick many) [ ] short soundeffects [ ] longer soundeffects [ ] short soundtracks [ ] long soundtracks [ ] the whole music for a film (or similar) [ ] life act: unimportant parts [ ] life act: important parts [ ] life act: whole life act * These surveys are (pick one) [ ] a bad idea [ ] a good idea * I'd like to have these things changed with the surveys Part IV - Can you help us? ========================== * I would be willing to help the Arts development (pick one) [ ] yes [ ] no * What I could contribute: I could (pick many) [ ] describe algorithms [ ] write modules [ ] write documentation [ ] work on the KDE gui [ ] work on other GUIs (Gnome/...) [ ] work on the Arts core (flow system/etc) [ ] provide some structures/effects/instruments I designed using Arts [ ] provide some WAVs/MP3s of my Arts sessions [ ] donate money/hardware (it is intended to make Arts run on SMP machines one day, but that probably has some time) * I think I unterstand the source code/relevant things (pick one) [ ] not at all [ ] only a little [ ] good enough to make my contribution [ ] very good -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Feb 14 23:24:13 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA21193 for ; Sun, 14 Feb 1999 23:24:12 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106719-16013>; Sun, 14 Feb 1999 23:23:17 +0100 Message-ID: <19990214232144.64838@space.twc.de> Date: Sun, 14 Feb 1999 23:21:44 +0100 From: Stefan Westerfeld To: ksynth@kde.org Subject: 4 band cutoff filter? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"QSKCpJRspsF.A.I5E.Vz0x2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/45 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Sun, 14 Feb 1999 23:23:17 +0100 Status: O Content-Length: 847 Lines: 32 Hi! Looking at generator 1.5 from native instruments and a "real" Waldorf pulse, I saw that one of the most important components for the synthesis they do is a 4 pole lowpass (cutoff) filter. It seems to have settings for: - cutoff frequency - resonance and converts an incoming signal into an outgoing signal, where frequencies beyond the cutoff frequency are lowered with -24 db (I am not sure wether this is per octave or overall). Anyone got a pointer or good idea how this is implemented? I think the frequency response will look something like that: | | ** |******* * | * | * +--------C----------- where the C indicates the Cutoff frequency. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 15 09:13:05 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id JAA22086 for ; Mon, 15 Feb 1999 09:13:04 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106092-650>; Mon, 15 Feb 1999 09:12:55 +0100 To: ksynth@kde.org Subject: Re: 4 band cutoff filter? References: <19990214232144.64838@space.twc.de> Sender: jams@cs.tut.fi (Jarno Seppanen) From: jams@cs.tut.fi (Jarno Seppanen) Reply-To: jams@cs.tut.fi (Jarno Seppanen) X-Url: http://www.modeemi.cs.tut.fi/~jams/ Date: 15 Feb 1999 10:12:29 +0200 In-Reply-To: Stefan Westerfeld's message of "Sun, 14 Feb 1999 23:21:44 +0100" Message-ID: X-Mailer: Gnus v5.4.66/Emacs 19.31 Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"BJi12uDjs9E.A.C_.Hc9x2"@alpha> Resent-From: ksynth@kde.org X-Mailing-List: archive/latest/46 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 15 Feb 1999 09:12:55 +0100 Status: O Content-Length: 655 Lines: 21 Stefan Westerfeld writes: > Hi! > > Looking at generator 1.5 from native instruments and a "real" Waldorf pulse, > I saw that one of the most important components for the synthesis they do > is a 4 pole lowpass (cutoff) filter. ... > Anyone got a pointer or good idea how this is implemented? > Robert Bristow-Johnson has released a nice set of equations for biquad (i.e. 2-pole) low-pass, band-pass etc. filters. They have been posted e.g. to the music-dsp mailing list. I have implemented the equations as filter modules in Sonic Flow (http://www.cs.tut.fi/sgn/arg/sf/), you could copy the code from there. -- -Jarno From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 15 10:15:45 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA22144 for ; Mon, 15 Feb 1999 10:15:45 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106092-649>; Mon, 15 Feb 1999 10:15:35 +0100 X-Lotus-FromDomain: EMPRISE From: hlapp@emprise.de To: ksynth@kde.org Message-ID: Date: Mon, 15 Feb 1999 10:14:31 +0100 Subject: Antwort: Arts Survey Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"xzr9hoGdoc.A.ADC.3W-x2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/47 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 15 Feb 1999 10:15:35 +0100 Status: O Content-Length: 620 Lines: 27 Von: Harald Lapp@EMPRISE on 15.02.99 10:14 hi! the survey is a very good idea. i'll fill it out asap and put it also on the www-page. the only thing for me, why i don't use aRts that much i would like to, is the gui: changing the position of modules/placing modules and connecting the modules is a bit slow on my system (k6/200). you've to wait some seconds, if you pick a module and place it somewhere, till you can continue work :-(. but it seems, that my system is fast enough to make some cool sound- synthesis. argh... i hate to complain something, when i'm not able to help fixing it :-(... cu <-harald From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 15 11:18:32 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA22218 for ; Mon, 15 Feb 1999 11:18:31 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106132-643>; Mon, 15 Feb 1999 11:18:22 +0100 X-Lotus-FromDomain: EMPRISE From: hlapp@emprise.de To: ksynth@kde.org Message-ID: Date: Mon, 15 Feb 1999 11:17:12 +0100 Subject: additional: gui Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"vPsfpfVMdPB.A.fDD.tR_x2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/48 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 15 Feb 1999 11:18:22 +0100 Status: O Content-Length: 362 Lines: 18 Von: Harald Lapp@EMPRISE on 15.02.99 11:17 hi,... it's me again... i just thought, if it may be possible to turn the wire-algorithm off so the wires will be drawn direct from one connector to the other, without going the best way around the other modules,... maybe it would'nt look that nice, but it could be optional for slower computers. bye <-harald From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 15 15:20:20 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA23025 for ; Mon, 15 Feb 1999 15:20:20 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106089-651>; Mon, 15 Feb 1999 15:20:22 +0100 Sender: kouhia@nic.funet.fi From: Juhana Sadeharju To: ksynth@kde.org In-reply-to: <19990214232144.64838@space.twc.de> (message from Stefan Westerfeld on Sun, 14 Feb 1999 23:21:44 +0100) Subject: Re: 4 band cutoff filter? Message-Id: <19990215142002Z7150-2277+5363@nic.funet.fi> Date: Mon, 15 Feb 1999 16:19:54 +0200 Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"VymKZc-qarK.A.Wt.m0Cy2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/49 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 15 Feb 1999 15:20:22 +0100 Status: O Content-Length: 193 Lines: 7 I have some reference info at home. Remind me if I forget to check it. A 4-pole filter can be made with two 2-pole filters but there could be something different going on here. Yours, Juhana From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 15 22:10:17 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id WAA25332 for ; Mon, 15 Feb 1999 22:10:16 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106087-649>; Mon, 15 Feb 1999 22:10:09 +0100 Date: Mon, 15 Feb 1999 16:14:53 -0500 Message-Id: <199902152114.QAA14220@lunar.skyport.net> X-Sender: mimestar@www.mimestar.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ksynth@kde.org From: Elliot Turner Subject: subscribe turnere@MimeStar.com Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"AZRorbVvCyJ.A.-PD.x0Iy2"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/50 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 15 Feb 1999 22:10:09 +0100 Status: O Content-Length: 0 Lines: 0 From ksynth-request@alpha.tat.physik.uni-tuebingen.de Mon Feb 22 14:19:00 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id OAA18135 for ; Mon, 22 Feb 1999 14:18:59 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106371-31408>; Mon, 22 Feb 1999 14:17:28 +0100 From: Stefan Westerfeld Message-Id: <199902221316.OAA18110@space.twc.de> Subject: Re: additional: gui To: ksynth@kde.org Date: Mon, 22 Feb 1999 14:16:15 +0100 (CET) In-Reply-To: from "hlapp@emprise.de" at Feb 15, 99 11:17:12 am Content-Type: text Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"nid6RsfnIwN.A.dyH.ojV02"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/51 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Mon, 22 Feb 1999 14:17:28 +0100 Status: O Content-Length: 988 Lines: 27 Hi! > hi,... it's me again... > > i just thought, if it may be possible to turn the > wire-algorithm off so the wires will be drawn > direct from one connector to the other, without > going the best way around the oth Expect that to be fixed in one of the next releases (probably the next). I have thought about throwing the routing algorithm in a seperate thread, so that rerouting won't block the GUI at all. This seems to be even easier to implement than the other one (since redrawing code needs not to be changed, and no new option has to be indroduced), and should make it possible to work without any delay on computers with any speed. Of course, optimizing the routing algorithm itself would be really good as well, but for now a quick and dirty solution is better than nothing. Currently, I am not "at home", so the next Arts release will have to wait 3-4 weeks or so. I intended to make 0.2.7 available before leaving, but my monitor gave up before :( Cu... Stefan From ksynth-request@alpha.tat.physik.uni-tuebingen.de Sun Mar 7 20:10:48 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA21539 for ; Sun, 7 Mar 1999 20:10:47 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <107346-281>; Sun, 7 Mar 1999 20:10:41 +0100 Message-ID: <19990307200834.04297@space.twc.de> Date: Sun, 7 Mar 1999 20:08:34 +0100 From: Stefan Westerfeld To: ksynth@kde.org Subject: New homepage location Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: <"-kJUvrlqFkJ.A.eaC.w8s42"@alpha> Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/52 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Sun, 7 Mar 1999 20:10:41 +0100 Status: O Content-Length: 346 Lines: 10 Hi! We needed to move the arts homepage again, since the linuxbox.com-pages went down. The new pages are currently under construction and may be found at http://linux.twc.de/arts. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From ksynth-request@alpha.tat.physik.uni-tuebingen.de Tue Mar 16 21:59:22 1999 Received: from alpha.tat.physik.uni-tuebingen.de (alpha.tat.physik.uni-tuebingen.de [134.2.170.97]) by space.twc.de (8.8.7/8.8.7) with ESMTP id VAA15271 for ; Tue, 16 Mar 1999 21:59:22 +0100 Received: by alpha.tat.physik.uni-tuebingen.de id <106408-26344>; Tue, 16 Mar 1999 22:00:14 +0100 Date: Tue, 16 Mar 1999 21:57:44 +0100 (MEZ) From: Harald Lapp X-Sender: aurora@inn.awi.fh-rosenheim.de To: ksynth@kde.org Subject: aRts-homepage online Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Old-Return-Path: X-Orcpt: rfc822;ksynth@kde.org Resent-Message-ID: Resent-From: ksynth@kde.org Reply-To: ksynth@kde.org X-Mailing-List: archive/latest/53 X-Loop: ksynth@kde.org Precedence: list Resent-Sender: ksynth-request@kde.org Resent-Date: Tue, 16 Mar 1999 22:00:14 +0100 Status: O Content-Length: 624 Lines: 21 hi! I`just finished the new aRts-homepage. All the old pages are now again online. there`s also a new link to a mail-archive, where you can find all the old mails, since the mailing-list is up and where of course all the new mails will be stored, too. if you don`t got the url of the page, yet: http://linux.twc.de/arts/ btw: comments on the new page are very welcome. if you don`t like it for any reason, or have problems of any kind with it, or find a mistake in it, or have addi- tional ideas for improving the site: just send me a mail. i would very much like to get some feedback from you. thanx & bye <-harald From MAILER-DAEMON@space.twc.de Sun Jun 13 20:40:20 1999 Received: from localhost (localhost) by space.twc.de (8.8.7/8.8.7) with internal id UAB26786; Sun, 13 Jun 1999 20:40:20 +0200 Date: Sun, 13 Jun 1999 20:40:20 +0200 From: Mail Delivery Subsystem Message-Id: <199906131840.UAB26786@space.twc.de> To: owner-arts@space.twc.de MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="UAB26786.929299220/space.twc.de" Subject: Returned mail: arts-list... aliasing/forwarding loop broken Auto-Submitted: auto-generated (failure) Status: RO Content-Length: 1371 Lines: 45 This is a MIME-encapsulated message --UAB26786.929299220/space.twc.de The original message was received at Sun, 13 Jun 1999 20:40:20 +0200 from majordomo@localhost ----- The following addresses had permanent fatal errors ----- arts-list ----- Transcript of session follows ----- 554 arts-list... aliasing/forwarding loop broken --UAB26786.929299220/space.twc.de Content-Type: message/delivery-status Reporting-MTA: dns; space.twc.de Arrival-Date: Sun, 13 Jun 1999 20:40:20 +0200 Final-Recipient: RFC822; arts-list@space.twc.de Action: failed Status: 5.4.6 Last-Attempt-Date: Sun, 13 Jun 1999 20:40:20 +0200 --UAB26786.929299220/space.twc.de Content-Type: text/rfc822-headers Return-Path: Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26786 for arts-list; Sun, 13 Jun 1999 20:40:20 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26781 for arts; Sun, 13 Jun 1999 20:40:19 +0200 From: Stefan Westerfeld Message-Id: <199906131840.UAA26781@space.twc.de> Subject: New Mailinglist Test To: arts@space.twc.de Date: Sun, 13 Jun 1999 20:40:19 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk --UAB26786.929299220/space.twc.de-- From owner-arts@space.twc.de Sun Jun 13 20:52:04 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26950 for arts-list; Sun, 13 Jun 1999 20:52:04 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26945 for arts@space.twc.de; Sun, 13 Jun 1999 20:52:03 +0200 From: Stefan Westerfeld Message-Id: <199906131852.UAA26945@space.twc.de> Subject: Test To: arts@space.twc.de Date: Sun, 13 Jun 1999 20:52:03 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Status: RO Content-Length: 26 Lines: 1 Again a mailinglist test. From owner-arts@space.twc.de Sun Jun 13 20:57:16 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26980 for arts-list; Sun, 13 Jun 1999 20:57:15 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26975 for arts@space.twc.de; Sun, 13 Jun 1999 20:57:15 +0200 From: Stefan Westerfeld Message-Id: <199906131857.UAA26975@space.twc.de> Subject: ListTest II To: arts@space.twc.de Date: Sun, 13 Jun 1999 20:57:14 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO Content-Length: 125 Lines: 6 Hi! Well, it seems like the aRts list is nearly up and running again, just have another test right now. Cu... Stefan From owner-arts@space.twc.de Sun Jun 13 23:44:34 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA27429 for arts-list; Sun, 13 Jun 1999 23:44:33 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA27426 for ; Sun, 13 Jun 1999 23:44:32 +0200 Received: from rhein-main.netsurf.de (root@dialin41.rhein-main.netsurf.de [194.163.193.41]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA28892 for ; Sun, 13 Jun 1999 17:25:53 +0200 Message-ID: <3763CB72.6AF0A120@rhein-main.netsurf.de> Date: Sun, 13 Jun 1999 17:17:06 +0200 From: Harald Lapp Organization: http://linux.twc.de/arts/ X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: ...test... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO Content-Length: 457 Lines: 11 the mailinglist is up and running... nice! :-) <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Mon Jun 14 09:39:17 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id JAA28343 for arts-list; Mon, 14 Jun 1999 09:39:17 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id JAA28340 for ; Mon, 14 Jun 1999 09:39:16 +0200 Received: from rhein-main.netsurf.de (root@dialin36.rhein-main.netsurf.de [194.163.193.36]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id DAA02948 for ; Mon, 14 Jun 1999 03:20:36 +0200 Message-ID: <376456D5.B88C622A@rhein-main.netsurf.de> Date: Mon, 14 Jun 1999 03:11:49 +0200 From: Harald Lapp Organization: http://linux.twc.de/arts/ X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: happy... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO Content-Length: 588 Lines: 14 ...birthday :-) many thanx to stefan, for starting developing such a great program, more than one year ago now. the first official announcement of aRts was at june, 14th 1998. <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Tue Jun 15 01:35:16 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA29810 for arts-list; Tue, 15 Jun 1999 01:35:12 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id BAA29805; Tue, 15 Jun 1999 01:35:11 +0200 Message-ID: <19990615013511.27861@space.twc.de> Date: Tue, 15 Jun 1999 01:35:11 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: aRts mailinglist: welcome back Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO Content-Length: 642 Lines: 17 Hi! Well, there is again a mailinglist for aRts - an analog realtime synthesizer running under linux. More info about aRts is avaiable at http://linux.twc.de/arts. I've got a list of subscribers to the old mailing list (which was formerly called ksynth@kde.org). I hope it was the complete/correct one ... anyway: I have subscribed you to the new list. You can post to it writing to: arts@space.twc.de (We'll see whether there will be @kde.org aliases again in the future). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Tue Jun 15 22:51:18 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA32009 for arts-list; Tue, 15 Jun 1999 22:51:07 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail.emprise.de (mail.emprise.de [212.105.193.97]) by space.twc.de (8.8.7/8.8.7) with SMTP id WAA32006 for ; Tue, 15 Jun 1999 22:51:06 +0200 From: hlapp@emprise.de Received: by mail.emprise.de(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id C1256791.00509F6A ; Tue, 15 Jun 1999 16:40:36 +0200 X-Lotus-FromDomain: EMPRISE To: arts@space.twc.de Message-ID: Date: Tue, 15 Jun 1999 16:36:24 +0200 Subject: midi-card 4 linux? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 376 Lines: 18 Von: Harald Lapp@EMPRISE on 15.06.99 16:36 hi! maybe someone in the list can help me? :-) i've bought me a digital-only audiocard (without midi- interface) and i want to throw my old sb16 out of my computer as soon as possible. are there any possibilities to use a midi-only card that exist out there with linux (instead of using the sb16 midi)? thanx & bye <-harald From owner-arts@space.twc.de Thu Jun 17 05:54:09 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id FAA02984 for arts-list; Thu, 17 Jun 1999 05:54:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id FAA02979; Thu, 17 Jun 1999 05:53:58 +0200 Message-ID: <19990617055358.45163@space.twc.de> Date: Thu, 17 Jun 1999 05:53:58 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: The first year Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 13032 Lines: 260 Hi! Well - originally, I just wanted to send that to Harald, since it should be published on the webpage (oh, if you like, please HTMLify it). But since the mailing list is for aRts discussion, I thought I could post it as well ;) Cu... Stefan [--- cut here ---] Happy birthday, aRts! Well, since aRts is now available to the public one year, I thought it would be a good idea to look wether it has developed well in that time, and what remains to be done. Let me introduce myself for a second: I am Stefan Westerfeld , the one who had the crazy idea of starting the project. For those of you who don't know anything about aRts: aRts stands for analog realtime synthesizer. It runs (mainly) under linux and is available under GPL, which makes it free software that comes with full source. More infos are at http://linux.twc.de/arts. The beginnings First of all, it hasn't been only a year. The first line of code was written in late 1997. Back then, aRts was developed under Aix/4.2 running on a PowerPC machine. The idea was to do modular sound synthesis, realtimeness wasn't possible back then, since Aix had no way to do so. Even CORBA was not an issue. I remember having a small C++ Program, which would parse some text files containing descriptions of the synthesis model. To get some useful data in there, there was even a Synth_STDIN module, which could read from stdin, so you could write something like: # mpeg3play nice_music.mp3 | synthesizer bandpassmodel.syn | play 44100 to get the nice_music.mp3 filtered though a bandpassmodel. Well, I had even a flanger and some echo structures back then, and I remember a friend of mine telling me "wow, that flanger sounds better than that we've got in our studio", which was pretty motivating :) So aRts started with a powerful and fully featured flow system from the first day. It could do recursive calculations soon after it started running at all. But it was not satisfying. After all, I started aRts not only to be modular, but to be easy to use. I could have been using CSound and be happy if I only wanted a program which I give some text files and which spits out a sound file after parsing them. Making it easy to use and powerful was the goal one year ago, and still is. GUI issues So aRts needed a GUI. It should allow confortable and easy to learn editing of the synthesis files that were created with text files before. Even at that time, there were ongoing GUI wars between KDE people and Gnome people. But what had synthesis to do with the GUI, after all? Why should it be a Gnome/KDE only app, if only one small part of it, the Builder itself, would even need to talk to the GUI? It should NOT. Gimp had the right to be tied to Gtk+ as they built their own toolkit anyway, when neither Gnome nor KDE existed. Gimp even had the right to be closely tied to the GUI, so that it could not easily ported away. But a new application like aRts, whose main purpose was sound/ signal processing and not drawing, and which was written in awareness that there are two toolkits/desktops/camps out there, had not, IMHO!! Silly to produce two apps of any kind and then start holy wars, just because people who like this or that desktop better. Besides other reasons, that was the motive why CORBA came into aRts. It would allow the synthesizer to simply do its work, alone, independant from the toolkit. Anyone who liked to do something with the synthesizer then could write a GUI in his/her favourite programming language, or a scriping system, or whatever else. I had to decide anyway which toolkit to use for the first builder, and I had made very good experiences with KDE (I ran it from the first betas, even on Motorola Risc 88100 systems, and Aix boxes, when Gnome didn't exist). Besides, my C++ knowledge was okay, and finally the thought that it wouldn't be TIED to KDE since CORBA abstraction lead to the conclusion that this decision couldn't be really wrong, as the amount to change it would be very limited. And others could develop a Gnome frontend parallely - until now there just never happened to be someone who did that... Midi & Realtime Well, the KDE GUI started to work, and the CORBA stuff (aRts is using mico as ORB) proved to be really stable and really helpful. Soon after that I was able to switch development over to a linux box, which made me able to work on realtime features. Arts became realtime aware relatively fast, and the idea to process midi data was born. Since aRts should never become a sequencer and a synthesizer, but remain a synthesizer, communication to sequencing programs was needed. The invention of the Midibus standard (a CORBA pased protocol to transfer midi events between applications) was the aRts way to solve that problem. What happend until today As you see, most core concepts of aRts were there in the first versions that were released officially (aRts was called KSynth in the first versions, but that name was dropped since aRts never intended to be a KDE only thing), and they are still there now. But what was vaguely known to be a good idea back then is proven to work now. Example: the midibus thing I talked of. Back then, it was just an idea that could be done. Today, the binding to Cantor (a linux sequencer) works quite fine, you can use the midi keyboard to improvise live on aRts. I have an experimental version of kooBase running on the midibus standard as well, and talked to Antonio Larossa about integration into his player classes, which are used in KDE apps such as kmid. The flow system is another example. In the first versions of aRts it was really slow, but worked. Now it supports much more features, like using structures again as modules, dynamic connections between modules AKA busses. Adding blockwise calculation for instance, combined with module optimization made aRts five times as fast in some structures, but of course added a lot of complexity to the recursive scheduling algorithms. Finally, releases have been announced, documentation has been written, the web site and mailing list are there now, and the code is more useful than ever. On the other hand, the people (and their machines out there) have changed. When CORBA was something unknown to most in 1997, the KDE and Gnome projects have made it something for everybody. Distributions like SuSE ship CORBA ORBs with their CDs, and more and more people know KOffice. And of course, the sequencer software, that is the condition under which a software synthesizer can be used to do real work, are now better than ever. KooBase is one of the newer ones, that looks really useful, on the other hand Cantor has appeared since a long time. There are talks about integration/code sharing/... going on all the time now between aRts/kooBase/Cantor. There will be some good solution, I am sure. Other sound processing programs of course could also benefit from aRts, well, lets see. The future Arts is a pretty nice piece of software already. But what is to do now? Well, to look back to the beginnings: making it easy to use and powerful was the goal one year ago, and still is. There are some new points in the "easy to use" goal now. One is the GUI Builder. As you see in the latest screenshots, aRts should provide sliders, buttons and control panels for the future. Of course they create new needs for ArtsBuilder, and require new features from the flow system. Also, their clean integration into the midi processing scheme seems important. When having a slider that controls for instance the cutoff of some filter in some midi instrument structure, one would like to have - only one slider on the screen - always that slider on the screen, even if no midi note is being played right now - hear the effect of turning this one slider in every note that is being played right now Well, aRts can't do that now, since this requires some new dynamic connection strategies between the GUI elements and the instruments. Of course, IF that parameter is also controllable via midi, one would like to have the slider move when midi events appear, and perhaps also the other way round. You see - more work on "powerful" requires more work on "easy to use" and vice versa. Overall, the flexibility of the modelling that aRts supports has to grow further. In the first versions, one was only modelling one structure, and then executed it. Then, it became evident that it would be great to execute more than one structure at once (on the same server at the same time). Busses then appeared to make structures communicate, and connect/disconnect themselves dynamically. So you can send signals generated inside one structure to another. Later, with midi routers, the functionality appeared to let modules create structures on demand. So when someone presses a key on the midi keyboard, aRts can generate just the modules it needs to generate that sound, and when the key is released again, the structure can be removed again. Structures inside structures appeared now, to allow a kind of "code reuse" inside structures. Since a user probably doesn't like to build the same effect from scratch every time he needs it, he can now make it a module and reuse it every time he needs it. But here is probably not the end of the development. As always, the task will be that a user needs to build models of his ideas of signal processing in aRts. But both, the modelling and the execution techniques need more refinement to provide concepts that allow intuitive usage and high flexibility. After all, the modelling challange is to model real studio technology in aRts, which just happens to be very different in purpose, interface and usage. A mixer is different from an instrument, and this differs from an effect. The structural modelling of aRts needs to be powerful enough to allow modelling them all in a reusable manner. The description of a mixer for instance should not contain a fixed number of mixing channels or a fixed equalizer style which is tied to the mixer. Instead, these should be parameters which at least should be changeable when the user starts the mixer, better even at runtime. Everything then needs to be integrated in a control model that allows either direct control from the user (via GUI interface), or via midi. Finally the claim aRts makes is to have a virtual studio of your own. You should enter your studio when starting aRts and loading something, and leave your studio when closing aRts. And you should be able to take your whole studio and put it on a floppy and go to some friend, and work with it there. >From the simplest effect to complex interacting systems, everything should consist of interacting small components. The idea of having a new filter scheme or a modification to an existing effect implemented in just a few minutes, without writing a line of code, is what aRts wants to be. Still the efficiency should be high, so that effects implemented as aRts structures are usable in daily work. Of course if something is great and used every day, someone can still handoptimize it in some C++ code fragment, which can then be used. Certainly this is also something where work needs to be done: aRts currently requires every module that it uses to be compiled in. Better would be of course to have them seperately, so that people can write&install new modules without needing to recompile aRts. A good API of course must be based on a flow system which is finished. The need for new control models and new flow system (execution & modelling) features is something that needs to be coordinated with the externalization of the aRts modules. Anyway, it would be a good idea to aim at having a lot of free high quality digital filters available in the future. Perhaps not even only for aRts, but also for wave editors, or other programs which may need something like that. But to find some conclusion words, as I am seeing how many motivated people are working on such things right now, things should improve a lot in the next time. Right now, there are many *ideas* like aRts and ATech, kooBase and Cantor, MMM and Sonic Flow, PSL and ESD, KAudioServer and libmediatool, and many others I have forgotten... most of them will mature, and the need to make things work that is very strong in the free software world will make those work together where it makes sense. The winners will be the end users, which will not only get a nice desktop environment like KDE/Gnome, nice free office tools like KOffice/Gnumeric, but also professional music software. I think with Gimp, KDE and Gnome, the people who do free software have accepted the idea that the power of programs expresses itself not only in inner beauty, but also in efficient user interfaces. Well, free software isn't only for programmers anymore, ... and perhaps soon even musicians will like it. If you like, go to http://linux.twc.de/arts now, and get the source, and play with aRts. Subscribe the mailinglist. Join the team. Build the future. From owner-arts@space.twc.de Thu Jun 17 07:43:53 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id HAA03382 for arts-list; Thu, 17 Jun 1999 07:43:53 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id HAA03379 for ; Thu, 17 Jun 1999 07:43:50 +0200 Received: from rhein-main.netsurf.de (root@dialin35.rhein-main.netsurf.de [194.163.193.35]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA26750 for ; Thu, 17 Jun 1999 01:25:21 +0200 Message-ID: <37683052.CDFF528B@rhein-main.netsurf.de> Date: Thu, 17 Jun 1999 01:16:34 +0200 From: Harald Lapp Organization: http://linux.twc.de/arts/ X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: [aRts] latest news... Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 642 Lines: 21 sorry, i´m too tired now, to write a lot. please have a look at the website (http://linux.twc.de/arts/) for more details June 17 ´99 arts-0.3.1 patch / status report online - arts-0.3.1 patch - status report online bye <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Fri Jun 18 05:38:19 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id FAA05621 for arts-list; Fri, 18 Jun 1999 05:38:13 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from elch.de.uu.net (elch.de.uu.net [192.76.144.55]) by space.twc.de (8.8.7/8.8.7) with ESMTP id FAA05618 for ; Fri, 18 Jun 1999 05:38:11 +0200 Received: from adinfinitum.de (pec-0-131.tnt1.s2.uunet.de [149.225.0.131]:2421) by elch.de.uu.net with ESMTP (5.65+:003/3.0.2) for id XAA08212; Thu, 17 Jun 1999 23:17:54 +0200 (MET DST) Received: (from bernhard@localhost) by adinfinitum.de (8.9.3/8.9.3) id XAA30826 for arts@space.twc.de; Thu, 17 Jun 1999 23:18:04 +0200 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.3.p0.Linux:990617231803:27362=_" In-Reply-To: <19990617055358.45163@space.twc.de> Date: Thu, 17 Jun 1999 23:18:03 +0200 (MEST) Organization: IGOR From: Bernhard Scheffold To: arts@space.twc.de Subject: aRTs-0.3.1.rpm Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2379 Lines: 76 This message is in MIME format --_=XFMail.1.3.p0.Linux:990617231803:27362=_ Content-Type: text/plain; charset=us-ascii Hi, I've produced an RPM of the current aRTs version (the .spec-file I used is attached). I took the package and installed it on the Linux box of a friend (my box and his use SuSE 6.1). Alas, aRTs does't produce any sound on his machine. I've tried a very simple structure (Play, Wave_Sin and frequency as described in the tutorial) which gives a CPU usage of 0 % on his machine. What could be wrong? What does the libtool provided with aRTs do with the binaries? Is my .spec-file incomplete? Bernhard. -- Bernhard Scheffold . Breisacherstrasse 37 . D-79106 Freiburg . Germany E-Mail: Bernhard.Scheffold@adinfinitum.de Fon: +49 761 288124 . Fax: +49 761 288299 --_=XFMail.1.3.p0.Linux:990617231803:27362=_ Content-Disposition: attachment; filename="arts-0.3.1.spec" Content-Transfer-Encoding: none Content-Description: arts-0.3.1.spec Content-Type: application/octet-stream; name=arts-0.3.1.spec; SizeOnDisk=1273 Summary: aRts Analog Real-Time Synthesizer Name: arts Version: 0.3.1 Release: 0 Copyright: GPL Group: Applications/Sound Source: arts-0.3.1.tar.gz Patch: arts-0.3.1.diff %description aRts simulates a complete "modular analog synthesizer" on your - digital - computer. Create sounds & music using small modules like oscillators for creating waveforms, various filters, modules for playing data on your speakers, mixers, faders,... You can build your complete setup with the gui of the system, using the modules - generators, effects and output - connected to each other. %prep %setup %patch -p1 %build #make -f Makefile.dist ./configure --with-micodir=/usr make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" %install make install #mkinstalldirs /opt/kde/share/applnk/Multimedia #/usr/bin/ginstall -c -m644 src/ksbuild/artsbuilder.kdelnk /opt/kde/share/applnk /Multimedia %post cd /opt/kde/bin chown root synth_server.bin chmod u+s synth_server.bin %files /opt/kde/bin/artsbuilder /opt/kde/bin/artsshell /opt/kde/bin/midisend /opt/kde/bin/synth_server /opt/kde/bin/synth_server.bin /opt/kde/include/idl/midibus.idl /opt/kde/include/idl/midibus.h /opt/kde/share/apps/artsbuilder/pics /opt/kde/share/doc/HTML/en/artsbuilder /opt/kde/share/applnk/Multimedia/artsbuilder.kdelnk --_=XFMail.1.3.p0.Linux:990617231803:27362=_-- End of MIME message From owner-arts@space.twc.de Sat Jun 19 00:42:52 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id AAA07820 for arts-list; Sat, 19 Jun 1999 00:42:49 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id AAA07815; Sat, 19 Jun 1999 00:42:48 +0200 Message-ID: <19990619004248.15441@space.twc.de> Date: Sat, 19 Jun 1999 00:42:48 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: aRTs-0.3.1.rpm References: <19990617055358.45163@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Bernhard Scheffold on Thu, Jun 17, 1999 at 11:18:03PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1561 Lines: 39 Hi! On Thu, Jun 17, 1999 at 11:18:03PM +0200, Bernhard Scheffold wrote: > I've produced an RPM of the current aRTs version (the .spec-file I used > is attached). I took the package and installed it on the Linux box of a friend > (my box and his use SuSE 6.1). Alas, aRTs does't produce any sound on his > machine. I've tried a very simple structure (Play, Wave_Sin and frequency as > described in the tutorial) which gives a CPU usage of 0 % on his machine. What > could be wrong? My first guess would be, that on his machine, either - soundplaying is completely broken (/dev/dsp won't do anything) Do other applications work playing audio data? - realtime soundplaying is broken (I at least observed very strange behaviour on a linux box with beta sblive drivers) Another thing you could do is watch the output that appears in the kvt window where synth_server is running (any error messages?). It is possible to get even more cryptic debug infos when using # artsshell -D 1 after starting synth_server. Another thing is, the mico versions on both machines should be the same. > What does the libtool provided with aRTs do with the binaries? It is just a general wrapper, which makes linking on different architectures behave the same - even when you are building shared libs for instance. > Is my .spec-file incomplete? I don't know much about .spec-files, but it looks quite ok. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Jun 21 06:32:12 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id GAA13551 for arts-list; Mon, 21 Jun 1999 06:31:58 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from elch.de.uu.net (elch.de.uu.net [192.76.144.55]) by space.twc.de (8.8.7/8.8.7) with ESMTP id GAA13548 for ; Mon, 21 Jun 1999 06:31:56 +0200 Received: from adinfinitum.de (pec-1-45.tnt1.s2.uunet.de [149.225.1.45]:3247) by elch.de.uu.net with ESMTP (5.65+:003/3.0.2) for id GAA25101; Mon, 21 Jun 1999 06:31:58 +0200 (MET DST) Received: (from bernhard@localhost) by adinfinitum.de (8.9.3/8.9.3) id XAA06633 for arts@space.twc.de; Sun, 20 Jun 1999 23:22:26 +0200 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990619004248.15441@space.twc.de> Date: Sun, 20 Jun 1999 23:22:26 +0200 (MEST) Organization: IGOR From: Bernhard Scheffold To: arts@space.twc.de Subject: Re: aRTs-0.3.1.rpm Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1117 Lines: 32 Hi Stefan, > My first guess would be, that on his machine, either > > - soundplaying is completely broken (/dev/dsp won't do anything) > Do other applications work playing audio data? > - realtime soundplaying is broken (I at least observed very strange > behaviour on a linux box with beta sblive drivers) I will have to look into that, especially since freeamp has stopped working on this machine, too. > Another thing you could do is watch the output that appears in the kvt > window where synth_server is running (any error messages?). It is possible > to get even more cryptic debug infos when using > ># artsshell -D 1 The output looks pretty much the same as the one I get on my machine. > after starting synth_server. Another thing is, the mico versions on both > machines should be the same. This should be the case, as both are installed from SuSE 6.1. Thank you very much for your reply, I hope we can resolve this problem, Bernhard. -- Bernhard Scheffold . Breisacherstrasse 37 . D-79106 Freiburg . Germany E-Mail: Bernhard.Scheffold@adinfinitum.de Fon: +49 761 288124 . Fax: +49 761 288299 From owner-arts@space.twc.de Fri Jul 2 23:32:06 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA04761 for arts-list; Fri, 2 Jul 1999 23:31:44 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA04758 for ; Fri, 2 Jul 1999 23:31:41 +0200 Received: from rhein-main.netsurf.de (root@dialin34.rhein-main.netsurf.de [194.163.193.34]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id XAA30212 for ; Fri, 2 Jul 1999 23:34:00 +0200 Message-ID: <377D2E28.104A859B@rhein-main.netsurf.de> Date: Fri, 02 Jul 1999 23:24:56 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: test - please ignore Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 400 Lines: 8 -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Sun Jul 4 15:15:47 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA08527 for arts-list; Sun, 4 Jul 1999 15:15:38 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA08524 for ; Sun, 4 Jul 1999 15:15:26 +0200 Received: from [212.238.75.184] (helo=obelix.vande-pol.demon.nl) by post.mail.nl.demon.net with esmtp (Exim 2.02 #1) id 110m9V-0003kc-00 for arts@space.twc.de; Sun, 4 Jul 1999 13:17:49 +0000 Received: from idefix.vande-pol.demon.nl (root@idefix.vande-pol.demon.nl [10.2.2.9]) by obelix.vande-pol.demon.nl (8.8.7/8.8.7) with ESMTP id PAA30358; Sun, 4 Jul 1999 15:15:56 +0200 Received: (from frank@localhost) by idefix.vande-pol.demon.nl (8.9.0/8.9.0) id PAA14827; Sun, 4 Jul 1999 15:15:58 +0200 From: Frank van de Pol Message-Id: <199907041315.PAA14827@idefix.vande-pol.demon.nl> Subject: aRts midibus sequencer client To: alsa-devel@alsa-project.org (alsa), alsa-user@alsa-project.org (alsa) Date: Sun, 4 Jul 1999 15:15:58 +0200 (CEST) Cc: arts@space.twc.de (aRts mailing list) X-Operating-System: Linux 2.2.9 i686 Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 603 Lines: 20 Inspired by Steve's Timidity client I hacked last night a sequencer client that allows you to use the aRts Analog Real-Time Synthesizer as a output device for the ALSA sequencer. The results are *very* cool, but the hack is quick and dirty. For those who are interested: my hack can be found at http://www.vande-pol.demon.nl/arts/ Have fun! Frank. +---- --- -- - - - - |Frank van de Pol -o) |Frank@vande-pol.demon.nl /\\ | _\_v |Linux - Why use Windows, since there is a door? | |ALSA Sequencer: http://www.vande-pol.demon.nl/alsa/ From owner-arts@space.twc.de Sun Jul 4 17:50:03 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id RAA08682 for arts-list; Sun, 4 Jul 1999 17:50:02 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id RAA08679 for ; Sun, 4 Jul 1999 17:50:00 +0200 Received: from rhein-main.netsurf.de (root@dialin41.rhein-main.netsurf.de [194.163.193.41]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA26358 for ; Sun, 4 Jul 1999 17:52:22 +0200 Message-ID: <377F8113.3A154793@rhein-main.netsurf.de> Date: Sun, 04 Jul 1999 17:43:15 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Re: aRts midibus sequencer client References: <199907041315.PAA14827@idefix.vande-pol.demon.nl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 883 Lines: 25 Frank van de Pol wrote: > > Inspired by Steve's Timidity client I hacked last night a sequencer client > that allows you to use the aRts Analog Real-Time Synthesizer as a output > device for the ALSA sequencer. The results are *very* cool, but the hack is > quick and dirty. > > For those who are interested: my hack can be found at > http://www.vande-pol.demon.nl/arts/ hi! this sounds very cool. i´ve not tried it yet, but i´ll put it on the aRts-newspage. thanx :-) <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Tue Jul 6 22:22:30 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA13408 for arts-list; Tue, 6 Jul 1999 22:22:20 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id WAA13403 for arts; Tue, 6 Jul 1999 22:22:19 +0200 From: Stefan Westerfeld Message-Id: <199907062022.WAA13403@space.twc.de> Subject: Killer App of the Month (fwd) To: arts@space.twc.de Date: Tue, 6 Jul 1999 22:22:18 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1434 Lines: 40 Hi! Good news... we've been choosen killer app of the month by 4Front-Tech (the OSS people). Also, the german Linux-Magazin has aRts on their web-page (don't know if on their printed edition). And finally: yes I am still alive ;) I just need to prepare for some written examinations (Klausuren) right now, but in two weeks it will be over, so I'll be able to make the next release soon after that. Cu... Stefan Forwarded message: > Dear Stefan, > > You'll be happy to know that your application aRTs has been selected > as the Killer App of the Month on the Open Sound System Home Page at > http://www.opensound.com - we invite you to check it out and make sure > that it's ok to use your logos (we'll remove it if you have objections). > > We hope that this link will bring some additional visitors to your website > and give your project some additional visibility as the OSS Homepage is > frequently accessed by not only Linux but UNIX users in general. > > We appreciate your support of the Open Sound System API and wish you good > luck in the future. > > Best regards > Dev Mazumdar > President > -- > ----------------------------------------------------------- > 4Front Technologies > 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA. > Tel: (310) 202 8530 URL: www.opensound.com > Fax: (310) 202 0496 Email: info@opensound.com > ----------------------------------------------------------- > From owner-arts@space.twc.de Wed Jul 7 00:19:29 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id AAA13728 for arts-list; Wed, 7 Jul 1999 00:19:28 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id AAA13725 for ; Wed, 7 Jul 1999 00:19:25 +0200 Received: from rhein-main.netsurf.de (root@dialin38.rhein-main.netsurf.de [194.163.193.38]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA03433 for ; Wed, 7 Jul 1999 00:21:53 +0200 Message-ID: <37827F5F.C7AF2FED@rhein-main.netsurf.de> Date: Wed, 07 Jul 1999 00:12:47 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Re: Killer App of the Month (fwd) References: <199907062022.WAA13403@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 829 Lines: 28 Stefan Westerfeld wrote: > > Hi! > > Good news... we've been choosen killer app of the month by 4Front-Tech (the > OSS people). > wow... that`s really good news, i think :-). many thanx to the people at 4Front. > Also, the german Linux-Magazin has aRts on their web-page (don't know if > on their printed edition). > no, it`s not in there... hopefully it will be in the next issue. page is updated, btw. cu <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Sat Jul 17 12:17:14 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA03816 for arts-list; Sat, 17 Jul 1999 12:16:40 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hotmail.com (wya-lfd73.hotmail.com [207.82.252.137]) by space.twc.de (8.8.7/8.8.7) with SMTP id MAA03813 for ; Sat, 17 Jul 1999 12:16:34 +0200 Received: (qmail 88703 invoked by uid 0); 17 Jul 1999 10:18:54 -0000 Message-ID: <19990717101854.88702.qmail@hotmail.com> Received: from 200.38.133.18 by www.hotmail.com with HTTP; Sat, 17 Jul 1999 03:18:35 PDT X-Originating-IP: [200.38.133.18] From: "Ernesto Cedillo Arias" To: arts@space.twc.de Subject: Problems compiling aRts Date: Sat, 17 Jul 1999 05:18:35 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO X-Status: A Content-Length: 22258 Lines: 496 Hello Could somebody help me? I am desperatly trying to compile arts but it is not succeding. My system is: PenitumII, 266 Mhz, 64MB Redhat 6.0 base Glibc 2.1.1 mico 2.2.5 audiofile 0.1.7 (the 0.1.6 with RedHat doesn't work) qt 1.44 egcs,c++ 1.1.2 This is what I all: {ernst@nemesis arts-0.3.1}# make make all-recursive make[1]: Entering directory `/tmp/test/arts-0.3.1' Making all in src make[2]: Entering directory `/tmp/test/arts-0.3.1/src' Making all in synthesizer make[3]: Entering directory `/tmp/test/arts-0.3.1/src/synthesizer' /usr/local/bin/idl --query-server-for-narrow synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth.cc /usr/local/bin/idl --query-server-for-narrow midibus.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midibus.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_server.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_impl.cc synth_impl.cc: In method `Synthesizer_impl::Synthesizer_impl()': synth_impl.cc:79: warning: int format, long int arg (arg 2) synth_impl.cc: In method `bool Synthesizer_impl::Exec()': synth_impl.cc:158: warning: ANSI C++ forbids implicit conversion from `void *' in initialization synth_impl.cc:176: warning: comparison between signed and unsigned synth_impl.cc:178: warning: comparison between signed and unsigned synth_impl.cc:179: warning: comparison between signed and unsigned synth_impl.cc: In method `MICO_Long Synthesizer_impl::createStructure1(class Arts::StructureDesc *)': synth_impl.cc:402: warning: int format, long int arg (arg 2) synth_impl.cc: In method `void Synthesizer_impl::removeDynamicConnections(class SynthModule *)': synth_impl.cc:604: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::createModule(MICO_Long, class Arts::ModuleDesc *)': synth_impl.cc:837: warning: unused variable `long int foundnr' synth_impl.cc:873: warning: control reaches end of non-void function `Synthesizer_impl::createModule(MICO_Long , Arts::ModuleDesc *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::remoteConnectModules(MICO_Long, MICO_Long, const clas s SequenceTmpl,0> &, class Arts::ArtsServer *)': synth_impl.cc:895: warning: comparison between signed and unsigned synth_impl.cc:902: warning: comparison between signed and unsigned synth_impl.cc:921: warning: control reaches end of non-void function `Synthesizer_impl::remoteConnectModules(M ICO_Long, MICO_Long, const SequenceTmpl,0> &, Arts::ArtsServer *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::localConnectModules(MICO_Long)': synth_impl.cc:925: warning: `return' with no value, in function returning non-void synth_impl.cc:939: warning: comparison between signed and unsigned synth_impl.cc:952: warning: comparison between signed and unsigned synth_impl.cc:972: warning: control reaches end of non-void function `Synthesizer_impl::localConnectModules(MI CO_Long)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::finalizeModules(MICO_Long)': synth_impl.cc:976: warning: `return' with no value, in function returning non-void synth_impl.cc:999: warning: control reaches end of non-void function `Synthesizer_impl::finalizeModules(MICO_L ong)' g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synthmodule.cc synthmodule.cc:26: warning: static member `SynthConnection::instances' re-declared as static synthmodule.cc:29: warning: static member `SynthBuffer::instances' re-declared as static synthmodule.cc:32: warning: static member `SynthBuffer::allbytes' re-declared as static synthmodule.cc: In method `void SynthModule::assignInConn(class SynthConnection *)': synthmodule.cc:140: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:145: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthModule::assignOutConn(class SynthConnection *)': synthmodule.cc:150: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:155: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `long int SynthModule::request(long int)': synthmodule.cc:215: warning: comparison between signed and unsigned synthmodule.cc: In method `long int SynthModule::calc(long int)': synthmodule.cc:275: warning: comparison between signed and unsigned synthmodule.cc:294: warning: comparison between signed and unsigned synthmodule.cc:306: warning: comparison between signed and unsigned synthmodule.cc:317: warning: comparison between signed and unsigned synthmodule.cc:326: warning: comparison between signed and unsigned synthmodule.cc:346: warning: comparison between signed and unsigned synthmodule.cc:352: warning: comparison between signed and unsigned synthmodule.cc:364: warning: comparison between signed and unsigned synthmodule.cc:371: warning: comparison between signed and unsigned synthmodule.cc: In method `SynthBuffer::SynthBuffer(float, long unsigned int)': synthmodule.cc:398: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::connectToSource(class SynthConnection *)': synthmodule.cc:457: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::disconnectFromSource(class SynthConnection *)': synthmodule.cc:471: warning: comparison between signed and unsigned synthmodule.cc:475: warning: ANSI C++ forbids implicit conversion from `void *' in assignment g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c ioevent.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c modules.cc modules.cc:46: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:46: warning: making `INVALUE' static modules.cc:47: warning: ANSI C++ forbids initialization of const member `CAPACITY_B' modules.cc:47: warning: making `CAPACITY_B' static modules.cc:48: warning: ANSI C++ forbids initialization of const member `CAPACITY_F' modules.cc:48: warning: making `CAPACITY_F' static modules.cc:50: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:50: warning: making `OUTVALUE' static modules.cc:189: warning: ANSI C++ forbids initialization of const member `INVALUE1' modules.cc:189: warning: making `INVALUE1' static modules.cc:190: warning: ANSI C++ forbids initialization of const member `INVALUE2' modules.cc:190: warning: making `INVALUE2' static modules.cc:191: warning: ANSI C++ forbids initialization of const member `PERCENTAGE' modules.cc:191: warning: making `PERCENTAGE' static modules.cc:192: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:192: warning: making `OUTVALUE' static modules.cc:227: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:227: warning: making `INVALUE' static modules.cc:228: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:228: warning: making `POS' static modules.cc:229: warning: ANSI C++ forbids initialization of const member `TOP' modules.cc:229: warning: making `TOP' static modules.cc:230: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:230: warning: making `OUTVALUE' static modules.cc:277: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:277: warning: making `INVALUE' static modules.cc:278: warning: ANSI C++ forbids initialization of const member `FACTOR' modules.cc:278: warning: making `FACTOR' static modules.cc:279: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:279: warning: making `OUTVALUE' static modules.cc:300: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:300: warning: making `INVALUE' static modules.cc:301: warning: ANSI C++ forbids initialization of const member `ADDIT' modules.cc:301: warning: making `ADDIT' static modules.cc:302: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:302: warning: making `OUTVALUE' static modules.cc:324: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:324: warning: making `INVALUE' static modules.cc:325: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:325: warning: making `TIME' static modules.cc:326: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:326: warning: making `OUTVALUE' static modules.cc:384: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:384: warning: making `FREQUENCY' static modules.cc:385: warning: ANSI C++ forbids initialization of const member `MODULATOR' modules.cc:385: warning: making `MODULATOR' static modules.cc:386: warning: ANSI C++ forbids initialization of const member `MODLEVEL' modules.cc:386: warning: making `MODLEVEL' static modules.cc:387: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:387: warning: making `POSITION' static modules.cc:411: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:411: warning: making `FREQUENCY' static modules.cc:412: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:412: warning: making `POSITION' static modules.cc:523: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:523: warning: making `POSITION' static modules.cc:524: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:524: warning: making `OUTVALUE' static modules.cc:554: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:554: warning: making `POSITION' static modules.cc:555: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:555: warning: making `FREQUENCY' static modules.cc:556: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:556: warning: making `OUTVALUE' static modules.cc:593: warning: ANSI C++ forbids initialization of const member `SPEED' modules.cc:593: warning: making `SPEED' static modules.cc:594: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:594: warning: making `FREQUENCY' static modules.cc:595: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:595: warning: making `POS' static modules.cc:668: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:668: warning: making `INVALUE' static modules.cc:703: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:703: warning: making `INVALUE_L' static modules.cc:704: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:704: warning: making `INVALUE_R' static modules.cc:705: warning: ANSI C++ forbids initialization of const member `CHANNELS' modules.cc:705: warning: making `CHANNELS' static modules.cc:880: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:880: warning: making `INVALUE_L' static modules.cc:881: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:881: warning: making `INVALUE_R' static modules.cc:985: warning: ANSI C++ forbids initialization of const member `ACTIVE' modules.cc:985: warning: making `ACTIVE' static modules.cc:986: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:986: warning: making `INVALUE' static modules.cc:987: warning: ANSI C++ forbids initialization of const member `ATTACK' modules.cc:987: warning: making `ATTACK' static modules.cc:988: warning: ANSI C++ forbids initialization of const member `DECAY' modules.cc:988: warning: making `DECAY' static modules.cc:989: warning: ANSI C++ forbids initialization of const member `SUSTAIN' modules.cc:989: warning: making `SUSTAIN' static modules.cc:990: warning: ANSI C++ forbids initialization of const member `RELEASE' modules.cc:990: warning: making `RELEASE' static modules.cc:993: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:993: warning: making `OUTVALUE' static modules.cc:994: warning: ANSI C++ forbids initialization of const member `DONE' modules.cc:994: warning: making `DONE' static modules.cc:997: warning: ANSI C++ forbids initialization of const member `NOOUT' modules.cc:997: warning: making `NOOUT' static modules.cc:1164: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1164: warning: making `INVALUE' static modules.cc:1183: warning: ANSI C++ forbids initialization of const member `READY' modules.cc:1183: warning: making `READY' static modules.cc:1209: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1209: warning: making `INVALUE' static modules.cc:1210: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:1210: warning: making `TIME' static modules.cc:1211: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1211: warning: making `OUTVALUE' static modules.cc:1288: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1288: warning: making `INVALUE' static modules.cc:1289: warning: ANSI C++ forbids initialization of const member `INSCALE' modules.cc:1289: warning: making `INSCALE' static modules.cc:1290: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1290: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c sound-linux.c gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c utils.c g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midi.cc In file included from midi.cc:23: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static midi.cc:152: warning: ANSI C++ forbids initialization of const member `CHANNEL' midi.cc:152: warning: making `CHANNEL' static midi.cc:153: warning: ANSI C++ forbids initialization of const member `MAXVOICES' midi.cc:153: warning: making `MAXVOICES' static midi.cc:154: warning: ANSI C++ forbids initialization of const member `COUNT' midi.cc:154: warning: making `COUNT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c structures.cc structures.cc: In method `MICO_Long ModuleDesc_impl::Width()': structures.cc:293: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long ModuleDesc_impl::Height()': structures.cc:305: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Width()': structures.cc:330: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Height()': structures.cc:342: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `void StructureDesc_impl::moveStructurePortDesc(class Arts::StructurePortDesc *, long int)': structures.cc:992: warning: comparison between signed and unsigned g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c artsobject.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c bus.cc bus.cc:154: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:154: warning: making `LEFT' static bus.cc:155: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:155: warning: making `RIGHT' static bus.cc:156: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:156: warning: making `BUSNAME' static bus.cc:189: warning: ANSI C++ forbids initialization of const member `CLIENTS' bus.cc:189: warning: making `CLIENTS' static bus.cc:190: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:190: warning: making `BUSNAME' static bus.cc:191: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:191: warning: making `LEFT' static bus.cc:192: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:192: warning: making `RIGHT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c cache.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c wav.cc wav.cc:130: warning: ANSI C++ forbids initialization of const member `LEFT' wav.cc:130: warning: making `LEFT' static wav.cc:131: warning: ANSI C++ forbids initialization of const member `RIGHT' wav.cc:131: warning: making `RIGHT' static wav.cc:132: warning: ANSI C++ forbids initialization of const member `DONE' wav.cc:132: warning: making `DONE' static wav.cc:133: warning: ANSI C++ forbids initialization of const member `FILENAME' wav.cc:133: warning: making `FILENAME' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c interfaces.cc In file included from interfaces.cc:22: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music.cc music.cc:32: warning: ANSI C++ forbids initialization of const member `INVALUE' music.cc:32: warning: making `INVALUE' static music.cc:33: warning: ANSI C++ forbids initialization of const member `FREQUENCY' music.cc:33: warning: making `FREQUENCY' static music.cc:35: warning: ANSI C++ forbids initialization of const member `OUTVALUE' music.cc:35: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music_orig.c ++ -I. -I../../include -O -fno-exceptions -fexceptions -O0 -I/usr/local/include -c NamingClient.cc -o Nam g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c receiver_impl.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c expand.cc /bin/sh ../../libtool --mode=link g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/synthesizer' Making all in shellutils make[3]: Entering directory `/tmp/test/arts-0.3.1/src/shellutils' /usr/local/bin/idl ../synthesizer/synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c synth.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c artsshell.cc artsshell.cc: In function `int main(int, char **)': artsshell.cc:44: warning: implicit declaration of function `int getopt(...)' artsshell.cc:48: `optarg' undeclared (first use this function) artsshell.cc:48: (Each undeclared identifier is reported only once artsshell.cc:48: for each function it appears in.) artsshell.cc:61: confused by earlier errors, bailing out make[3]: *** [artsshell.o] Error 1 make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/shellutils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/test/arts-0.3.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/test/arts-0.3.1' make: *** [all-recursive-am] Error 2 [ernst@nemesis arts-0.3.1]# On the other hand I compiled mico2.2.7 and then atttempted to patch arts.0.3.1 source, but I got rejctions. Is there any other patch I could use? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-arts@space.twc.de Sat Jul 17 12:17:14 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA03820 for arts-list; Sat, 17 Jul 1999 12:17:08 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hotmail.com (wya-lfd122.hotmail.com [207.82.252.186]) by space.twc.de (8.8.7/8.8.7) with SMTP id MAA03817 for ; Sat, 17 Jul 1999 12:16:51 +0200 Received: (qmail 77548 invoked by uid 0); 17 Jul 1999 10:19:09 -0000 Message-ID: <19990717101909.77547.qmail@hotmail.com> Received: from 200.38.133.18 by www.hotmail.com with HTTP; Sat, 17 Jul 1999 03:18:51 PDT X-Originating-IP: [200.38.133.18] From: "Ernesto Cedillo Arias" To: arts@space.twc.de Subject: Problems compiling aRts Date: Sat, 17 Jul 1999 05:18:51 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 22258 Lines: 496 Hello Could somebody help me? I am desperatly trying to compile arts but it is not succeding. My system is: PenitumII, 266 Mhz, 64MB Redhat 6.0 base Glibc 2.1.1 mico 2.2.5 audiofile 0.1.7 (the 0.1.6 with RedHat doesn't work) qt 1.44 egcs,c++ 1.1.2 This is what I all: {ernst@nemesis arts-0.3.1}# make make all-recursive make[1]: Entering directory `/tmp/test/arts-0.3.1' Making all in src make[2]: Entering directory `/tmp/test/arts-0.3.1/src' Making all in synthesizer make[3]: Entering directory `/tmp/test/arts-0.3.1/src/synthesizer' /usr/local/bin/idl --query-server-for-narrow synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth.cc /usr/local/bin/idl --query-server-for-narrow midibus.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midibus.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_server.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_impl.cc synth_impl.cc: In method `Synthesizer_impl::Synthesizer_impl()': synth_impl.cc:79: warning: int format, long int arg (arg 2) synth_impl.cc: In method `bool Synthesizer_impl::Exec()': synth_impl.cc:158: warning: ANSI C++ forbids implicit conversion from `void *' in initialization synth_impl.cc:176: warning: comparison between signed and unsigned synth_impl.cc:178: warning: comparison between signed and unsigned synth_impl.cc:179: warning: comparison between signed and unsigned synth_impl.cc: In method `MICO_Long Synthesizer_impl::createStructure1(class Arts::StructureDesc *)': synth_impl.cc:402: warning: int format, long int arg (arg 2) synth_impl.cc: In method `void Synthesizer_impl::removeDynamicConnections(class SynthModule *)': synth_impl.cc:604: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::createModule(MICO_Long, class Arts::ModuleDesc *)': synth_impl.cc:837: warning: unused variable `long int foundnr' synth_impl.cc:873: warning: control reaches end of non-void function `Synthesizer_impl::createModule(MICO_Long , Arts::ModuleDesc *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::remoteConnectModules(MICO_Long, MICO_Long, const clas s SequenceTmpl,0> &, class Arts::ArtsServer *)': synth_impl.cc:895: warning: comparison between signed and unsigned synth_impl.cc:902: warning: comparison between signed and unsigned synth_impl.cc:921: warning: control reaches end of non-void function `Synthesizer_impl::remoteConnectModules(M ICO_Long, MICO_Long, const SequenceTmpl,0> &, Arts::ArtsServer *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::localConnectModules(MICO_Long)': synth_impl.cc:925: warning: `return' with no value, in function returning non-void synth_impl.cc:939: warning: comparison between signed and unsigned synth_impl.cc:952: warning: comparison between signed and unsigned synth_impl.cc:972: warning: control reaches end of non-void function `Synthesizer_impl::localConnectModules(MI CO_Long)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::finalizeModules(MICO_Long)': synth_impl.cc:976: warning: `return' with no value, in function returning non-void synth_impl.cc:999: warning: control reaches end of non-void function `Synthesizer_impl::finalizeModules(MICO_L ong)' g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synthmodule.cc synthmodule.cc:26: warning: static member `SynthConnection::instances' re-declared as static synthmodule.cc:29: warning: static member `SynthBuffer::instances' re-declared as static synthmodule.cc:32: warning: static member `SynthBuffer::allbytes' re-declared as static synthmodule.cc: In method `void SynthModule::assignInConn(class SynthConnection *)': synthmodule.cc:140: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:145: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthModule::assignOutConn(class SynthConnection *)': synthmodule.cc:150: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:155: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `long int SynthModule::request(long int)': synthmodule.cc:215: warning: comparison between signed and unsigned synthmodule.cc: In method `long int SynthModule::calc(long int)': synthmodule.cc:275: warning: comparison between signed and unsigned synthmodule.cc:294: warning: comparison between signed and unsigned synthmodule.cc:306: warning: comparison between signed and unsigned synthmodule.cc:317: warning: comparison between signed and unsigned synthmodule.cc:326: warning: comparison between signed and unsigned synthmodule.cc:346: warning: comparison between signed and unsigned synthmodule.cc:352: warning: comparison between signed and unsigned synthmodule.cc:364: warning: comparison between signed and unsigned synthmodule.cc:371: warning: comparison between signed and unsigned synthmodule.cc: In method `SynthBuffer::SynthBuffer(float, long unsigned int)': synthmodule.cc:398: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::connectToSource(class SynthConnection *)': synthmodule.cc:457: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::disconnectFromSource(class SynthConnection *)': synthmodule.cc:471: warning: comparison between signed and unsigned synthmodule.cc:475: warning: ANSI C++ forbids implicit conversion from `void *' in assignment g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c ioevent.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c modules.cc modules.cc:46: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:46: warning: making `INVALUE' static modules.cc:47: warning: ANSI C++ forbids initialization of const member `CAPACITY_B' modules.cc:47: warning: making `CAPACITY_B' static modules.cc:48: warning: ANSI C++ forbids initialization of const member `CAPACITY_F' modules.cc:48: warning: making `CAPACITY_F' static modules.cc:50: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:50: warning: making `OUTVALUE' static modules.cc:189: warning: ANSI C++ forbids initialization of const member `INVALUE1' modules.cc:189: warning: making `INVALUE1' static modules.cc:190: warning: ANSI C++ forbids initialization of const member `INVALUE2' modules.cc:190: warning: making `INVALUE2' static modules.cc:191: warning: ANSI C++ forbids initialization of const member `PERCENTAGE' modules.cc:191: warning: making `PERCENTAGE' static modules.cc:192: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:192: warning: making `OUTVALUE' static modules.cc:227: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:227: warning: making `INVALUE' static modules.cc:228: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:228: warning: making `POS' static modules.cc:229: warning: ANSI C++ forbids initialization of const member `TOP' modules.cc:229: warning: making `TOP' static modules.cc:230: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:230: warning: making `OUTVALUE' static modules.cc:277: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:277: warning: making `INVALUE' static modules.cc:278: warning: ANSI C++ forbids initialization of const member `FACTOR' modules.cc:278: warning: making `FACTOR' static modules.cc:279: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:279: warning: making `OUTVALUE' static modules.cc:300: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:300: warning: making `INVALUE' static modules.cc:301: warning: ANSI C++ forbids initialization of const member `ADDIT' modules.cc:301: warning: making `ADDIT' static modules.cc:302: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:302: warning: making `OUTVALUE' static modules.cc:324: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:324: warning: making `INVALUE' static modules.cc:325: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:325: warning: making `TIME' static modules.cc:326: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:326: warning: making `OUTVALUE' static modules.cc:384: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:384: warning: making `FREQUENCY' static modules.cc:385: warning: ANSI C++ forbids initialization of const member `MODULATOR' modules.cc:385: warning: making `MODULATOR' static modules.cc:386: warning: ANSI C++ forbids initialization of const member `MODLEVEL' modules.cc:386: warning: making `MODLEVEL' static modules.cc:387: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:387: warning: making `POSITION' static modules.cc:411: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:411: warning: making `FREQUENCY' static modules.cc:412: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:412: warning: making `POSITION' static modules.cc:523: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:523: warning: making `POSITION' static modules.cc:524: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:524: warning: making `OUTVALUE' static modules.cc:554: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:554: warning: making `POSITION' static modules.cc:555: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:555: warning: making `FREQUENCY' static modules.cc:556: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:556: warning: making `OUTVALUE' static modules.cc:593: warning: ANSI C++ forbids initialization of const member `SPEED' modules.cc:593: warning: making `SPEED' static modules.cc:594: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:594: warning: making `FREQUENCY' static modules.cc:595: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:595: warning: making `POS' static modules.cc:668: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:668: warning: making `INVALUE' static modules.cc:703: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:703: warning: making `INVALUE_L' static modules.cc:704: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:704: warning: making `INVALUE_R' static modules.cc:705: warning: ANSI C++ forbids initialization of const member `CHANNELS' modules.cc:705: warning: making `CHANNELS' static modules.cc:880: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:880: warning: making `INVALUE_L' static modules.cc:881: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:881: warning: making `INVALUE_R' static modules.cc:985: warning: ANSI C++ forbids initialization of const member `ACTIVE' modules.cc:985: warning: making `ACTIVE' static modules.cc:986: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:986: warning: making `INVALUE' static modules.cc:987: warning: ANSI C++ forbids initialization of const member `ATTACK' modules.cc:987: warning: making `ATTACK' static modules.cc:988: warning: ANSI C++ forbids initialization of const member `DECAY' modules.cc:988: warning: making `DECAY' static modules.cc:989: warning: ANSI C++ forbids initialization of const member `SUSTAIN' modules.cc:989: warning: making `SUSTAIN' static modules.cc:990: warning: ANSI C++ forbids initialization of const member `RELEASE' modules.cc:990: warning: making `RELEASE' static modules.cc:993: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:993: warning: making `OUTVALUE' static modules.cc:994: warning: ANSI C++ forbids initialization of const member `DONE' modules.cc:994: warning: making `DONE' static modules.cc:997: warning: ANSI C++ forbids initialization of const member `NOOUT' modules.cc:997: warning: making `NOOUT' static modules.cc:1164: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1164: warning: making `INVALUE' static modules.cc:1183: warning: ANSI C++ forbids initialization of const member `READY' modules.cc:1183: warning: making `READY' static modules.cc:1209: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1209: warning: making `INVALUE' static modules.cc:1210: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:1210: warning: making `TIME' static modules.cc:1211: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1211: warning: making `OUTVALUE' static modules.cc:1288: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1288: warning: making `INVALUE' static modules.cc:1289: warning: ANSI C++ forbids initialization of const member `INSCALE' modules.cc:1289: warning: making `INSCALE' static modules.cc:1290: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1290: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c sound-linux.c gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c utils.c g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midi.cc In file included from midi.cc:23: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static midi.cc:152: warning: ANSI C++ forbids initialization of const member `CHANNEL' midi.cc:152: warning: making `CHANNEL' static midi.cc:153: warning: ANSI C++ forbids initialization of const member `MAXVOICES' midi.cc:153: warning: making `MAXVOICES' static midi.cc:154: warning: ANSI C++ forbids initialization of const member `COUNT' midi.cc:154: warning: making `COUNT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c structures.cc structures.cc: In method `MICO_Long ModuleDesc_impl::Width()': structures.cc:293: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long ModuleDesc_impl::Height()': structures.cc:305: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Width()': structures.cc:330: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Height()': structures.cc:342: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `void StructureDesc_impl::moveStructurePortDesc(class Arts::StructurePortDesc *, long int)': structures.cc:992: warning: comparison between signed and unsigned g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c artsobject.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c bus.cc bus.cc:154: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:154: warning: making `LEFT' static bus.cc:155: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:155: warning: making `RIGHT' static bus.cc:156: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:156: warning: making `BUSNAME' static bus.cc:189: warning: ANSI C++ forbids initialization of const member `CLIENTS' bus.cc:189: warning: making `CLIENTS' static bus.cc:190: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:190: warning: making `BUSNAME' static bus.cc:191: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:191: warning: making `LEFT' static bus.cc:192: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:192: warning: making `RIGHT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c cache.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c wav.cc wav.cc:130: warning: ANSI C++ forbids initialization of const member `LEFT' wav.cc:130: warning: making `LEFT' static wav.cc:131: warning: ANSI C++ forbids initialization of const member `RIGHT' wav.cc:131: warning: making `RIGHT' static wav.cc:132: warning: ANSI C++ forbids initialization of const member `DONE' wav.cc:132: warning: making `DONE' static wav.cc:133: warning: ANSI C++ forbids initialization of const member `FILENAME' wav.cc:133: warning: making `FILENAME' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c interfaces.cc In file included from interfaces.cc:22: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music.cc music.cc:32: warning: ANSI C++ forbids initialization of const member `INVALUE' music.cc:32: warning: making `INVALUE' static music.cc:33: warning: ANSI C++ forbids initialization of const member `FREQUENCY' music.cc:33: warning: making `FREQUENCY' static music.cc:35: warning: ANSI C++ forbids initialization of const member `OUTVALUE' music.cc:35: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music_orig.c ++ -I. -I../../include -O -fno-exceptions -fexceptions -O0 -I/usr/local/include -c NamingClient.cc -o Nam g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c receiver_impl.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c expand.cc /bin/sh ../../libtool --mode=link g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/synthesizer' Making all in shellutils make[3]: Entering directory `/tmp/test/arts-0.3.1/src/shellutils' /usr/local/bin/idl ../synthesizer/synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c synth.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c artsshell.cc artsshell.cc: In function `int main(int, char **)': artsshell.cc:44: warning: implicit declaration of function `int getopt(...)' artsshell.cc:48: `optarg' undeclared (first use this function) artsshell.cc:48: (Each undeclared identifier is reported only once artsshell.cc:48: for each function it appears in.) artsshell.cc:61: confused by earlier errors, bailing out make[3]: *** [artsshell.o] Error 1 make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/shellutils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/test/arts-0.3.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/test/arts-0.3.1' make: *** [all-recursive-am] Error 2 [ernst@nemesis arts-0.3.1]# On the other hand I compiled mico2.2.7 and then atttempted to patch arts.0.3.1 source, but I got rejctions. Is there any other patch I could use? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-arts@space.twc.de Mon Jul 19 01:18:38 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA06603 for arts-list; Mon, 19 Jul 1999 01:18:20 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id BAA06598; Mon, 19 Jul 1999 01:18:18 +0200 Message-ID: <19990719011818.04390@space.twc.de> Date: Mon, 19 Jul 1999 01:18:18 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems compiling aRts References: <19990717101854.88702.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990717101854.88702.qmail@hotmail.com>; from Ernesto Cedillo Arias on Sat, Jul 17, 1999 at 05:18:35AM -0500 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2066 Lines: 56 Hi! On Sat, Jul 17, 1999 at 05:18:35AM -0500, Ernesto Cedillo Arias wrote: > Could somebody help me? I am desperatly trying to compile arts but it is not > succeding. > My system is: PenitumII, 266 Mhz, 64MB > Redhat 6.0 base > Glibc 2.1.1 > mico 2.2.5 > audiofile 0.1.7 (the 0.1.6 with RedHat doesn't work) > qt 1.44 > egcs,c++ 1.1.2 > > This is what I all: > > {ernst@nemesis arts-0.3.1}# make > [...] > g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall > -c > artsshell.cc > artsshell.cc: In function `int main(int, char **)': > artsshell.cc:44: warning: implicit declaration of function `int getopt(...)' > artsshell.cc:48: `optarg' undeclared (first use this function) > artsshell.cc:48: (Each undeclared identifier is reported only once > artsshell.cc:48: for each function it appears in.) > artsshell.cc:61: confused by earlier errors, bailing out > make[3]: *** [artsshell.o] Error 1 > make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/shellutils' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/tmp/test/arts-0.3.1/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/test/arts-0.3.1' > make: *** [all-recursive-am] Error 2 > [ernst@nemesis arts-0.3.1]# > That is easy to solve: add #include as first line of artsshell.cc. > On the other hand I compiled mico2.2.7 and then atttempted to patch > arts.0.3.1 source, but I got rejctions. Is there any other patch I could > use? It shouldn't reject. At least it works for me with patch -p0 < foo.patch in the _directory you extracted from_ (not in the arts-0.3.1 directory itself, but one level higher). But you need that patch only when using mico-2.2.7, not for mico2.2.5 that is in your list above. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Tue Jul 20 22:51:49 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA11198 for arts-list; Tue, 20 Jul 1999 22:51:19 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hotmail.com (wya-lfd84.hotmail.com [207.82.252.148]) by space.twc.de (8.8.7/8.8.7) with SMTP id WAA11195 for ; Tue, 20 Jul 1999 22:51:15 +0200 Received: (qmail 70415 invoked by uid 0); 20 Jul 1999 20:53:42 -0000 Message-ID: <19990720205342.70414.qmail@hotmail.com> Received: from 200.38.138.215 by www.hotmail.com with HTTP; Tue, 20 Jul 1999 13:53:42 PDT X-Originating-IP: [200.38.138.215] From: "Ernesto Cedillo Arias" To: arts@space.twc.de Subject: Re: Problems compiling aRts Date: Tue, 20 Jul 1999 15:53:42 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 300 Lines: 10 Thank you As a matter of fact I have reinstalled redhat 5.2 and I compiled aRts without damage. I will setup 6.0 on anoher machine and take your advise for compiling the synth, Ernesto ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-arts@space.twc.de Wed Jul 21 01:22:50 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA11592 for arts-list; Wed, 21 Jul 1999 01:22:48 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id BAA11589 for ; Wed, 21 Jul 1999 01:22:44 +0200 Received: from rhein-main.netsurf.de (root@dialin36.rhein-main.netsurf.de [194.163.193.36]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA12473 for ; Wed, 21 Jul 1999 01:25:42 +0200 Message-ID: <37950343.685D1366@rhein-main.netsurf.de> Date: Wed, 21 Jul 1999 01:16:19 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: [arts] - website update Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 963 Lines: 22 July 21 ´99 - realaudio-stream available There´s now the possibility to listen to realaudio- streams of aRts-demosongs. just klick on the ´demo- song´-section in the menu to get a list of the avai- lable demosongs and realaudio-streams. I´ve had some problems with the account the last weeks, but i hope they are solved and there are no broken links. There´s only one demosong available yet. if you´ve made a nice song or just some cool experiments, please tell us. so we could post them on the demo-pages and put also a realaudio-stream on- line. thanx! -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Sun Jul 25 11:49:46 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id LAA29274 for arts-list; Sun, 25 Jul 1999 11:49:39 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from ghs.ssd.k12.wa.us (root@[216.186.55.11]) by space.twc.de (8.8.7/8.8.7) with ESMTP id LAA29271 for ; Sun, 25 Jul 1999 11:49:35 +0200 Received: from ghs.ssd.k12.wa.us (IDENT:root@1Cust45.tnt4.krk1.da.uu.net [208.254.1.45]) by ghs.ssd.k12.wa.us (8.9.3/8.8.7) with SMTP id CAA06537 for ; Sun, 25 Jul 1999 02:55:01 -0700 Message-ID: <379ADDBB.1C10942@ghs.ssd.k12.wa.us> Date: Sun, 25 Jul 1999 09:49:47 +0000 From: Peter Davis X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Problems with RH6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO X-Status: A Content-Length: 1530 Lines: 44 I just downloaded aRts and found that it doesn't quite work right on my almost-out-of-the-box RedHat 6.0 system. The first problem was that it wouldn't compile - it gave some messages about audiofile, so I downloaded version 1.7 (RH6 comes with 1.6-5) and it compiled with out errors (lots of warnings though). But finally after it finished, it runs for about 10 seconds and then segfaults. Another interesting thing is that when another program is using the soundcard it segfaults in only about 5 seconds. Could this be a problem with the kernel driver? It would be interesting to find if other people have problems with version 2.2 (I'm using 2.2.5-15). I'm using Arts-0.3.1, audiofile-1.7, egcs-2.91.66, and mico-2.2.4. Any clues? Or am I just dead? Thank you! -- Execute every act of thy life as though it were thy last. -- Marcus Aurelius , , /( )` \ \__ / | /- _ `-/ ' (/\/ \ \ /\ / / | ` \ O O ) | `-^--'`< ' (_.) _ ) / `.___/` / `-----' / <----. __ / __ \ <----|====O)))==) \) /====PeTeR-DaViS <----' `--' `.__,' \ | pdavis@ | \ghs.ssd/ ____( (.k12/ \______ ,' ,----'.wa| \ `--{_*_*_*_.us) \/ (if you don't have a fixed-width font that may turn out a little screwy) From owner-arts@space.twc.de Sun Jul 25 21:32:34 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id VAA32262 for arts-list; Sun, 25 Jul 1999 21:32:32 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hotmail.com (wya-lfd79.hotmail.com [207.82.252.143]) by space.twc.de (8.8.7/8.8.7) with SMTP id VAA32259 for ; Sun, 25 Jul 1999 21:32:28 +0200 Received: (qmail 41361 invoked by uid 0); 25 Jul 1999 19:32:47 -0000 Message-ID: <19990725193247.41360.qmail@hotmail.com> Received: from 148.233.144.111 by www.hotmail.com with HTTP; Sun, 25 Jul 1999 12:32:46 PDT X-Originating-IP: [148.233.144.111] From: "Ernesto Cedillo Arias" To: arts@space.twc.de Subject: Re: Problems with RH6 Date: Sun, 25 Jul 1999 14:32:46 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1133 Lines: 22 Definitely redhat 6.0's audiofile1.6 is really not working at all. I am glad not to be the only person to notice that fact. I had several problems while attempting to compile arts in 6.0. I got some advise from this list but anyway I have chosen to go back to redhat 5.2, now I am purchasing Linux Mandrake and I hope aRts will work on it. Maybe it is just my point of view but I think Redhat is lacking flexibility about KDE's installation now and there's a preference to gnome. I don't matter I am a musician not a programmer. Maybe you should go back to 5.2 and wait for KDE 2.0 release and then change your kernel on the basis of the 5.2 system and not totally upgrade the whole thing. I know changing to 2.2 is almost equivalent to go into another kind of system but I think the structure within 5.2 for KDE is better, more independent. Maybe you should try 2.2.10 I am using it on another machine and it seems to work nice with sound apps. I will try the compilation anyway, and see you later. Ernesto ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-arts@space.twc.de Mon Jul 26 13:41:38 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id NAA05005 for arts-list; Mon, 26 Jul 1999 13:40:04 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id NAA05000; Mon, 26 Jul 1999 13:40:01 +0200 Message-ID: <19990726134000.23490@space.twc.de> Date: Mon, 26 Jul 1999 13:40:00 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with RH6 References: <379ADDBB.1C10942@ghs.ssd.k12.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <379ADDBB.1C10942@ghs.ssd.k12.wa.us>; from Peter Davis on Sun, Jul 25, 1999 at 09:49:47AM +0000 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1581 Lines: 33 Hi! On Sun, Jul 25, 1999 at 09:49:47AM +0000, Peter Davis wrote: > I just downloaded aRts and found that it doesn't quite work right on > my almost-out-of-the-box RedHat 6.0 system. The first problem was > that it wouldn't compile - it gave some messages about audiofile, so I > downloaded version 1.7 (RH6 comes with 1.6-5) and it compiled with out > errors (lots of warnings though). Well, ok. Debugging these errors of course could have been possible if you posted them, but if it works with 1.7 thats fine, too. I am using 0.1.6 on debian 2.1, but I had to hand edit one header file, which had two closing brackets if __cplusplus was defined. > But finally after it finished, it > runs for about 10 seconds and then segfaults. Another interesting > thing is that when another program is using the soundcard it segfaults > in only about 5 seconds. Could this be a problem with the kernel > driver? It would be interesting to find if other people have problems > with version 2.2 (I'm using 2.2.5-15). >From what you tell, it sounds like a kernel/driver problem. Are you sure you have set up DMA and IRQ and that stuff correctly? This usually gives ugly problems when not done properly. Try looking in /var/log/messages if there are some unusual error messages. Your problems could also be card specific. I am for instance using linux 2.2.9 with an AWE64 (using the SB16 driver), and it works really fine. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Jul 30 23:58:40 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA07586 for arts-list; Fri, 30 Jul 1999 23:58:05 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id XAA07581 for arts; Fri, 30 Jul 1999 23:58:00 +0200 From: Stefan Westerfeld Message-Id: <199907302158.XAA07581@space.twc.de> Subject: aRts-0.3.2 released. To: arts@space.twc.de Date: Fri, 30 Jul 1999 23:57:58 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1292 Lines: 36 Hi! Well, finally, there is it: the next generation of aRts, aRts 0.3.2 is released. I tried to update the docs more or less good, so you can start making instruments with frontpanels now (or similar nice things). Just play with it ;). Changes since arts-0.3.1: ------------------------- - Widgets should be usable as subwidgets in most useful combinations, so you can create panels inside panels inside panels, which makes it possible to give reusable components (such as effects) a gui which is reusable as well. - New module Gui_SUB_PANEL to support substructuring. On the other hand it makes it possible to have "front panels" for instruments finally, where you can change instrument parameters on the fly. - Changes in MidiRouter, new PARAM_GET/SET modules and others for the "front panel" stuff. - New module Gui_INSTRUMENT_MAPPER allows assigning instruments to midi channels on the fly (with user interface while synthesis is running). - New modules Gui_POTI (turning knob for parameters) and Gui_WINDOW. - Some work on parent/child widgets and layout in the guiserver. - Autoloading of example structures (which install themselves now) and everything in $HOME/arts/structures. - Some bugfixes ;) Cu... Stefan From owner-arts@space.twc.de Sat Jul 31 22:19:16 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA14330 for arts-list; Sat, 31 Jul 1999 22:19:08 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from reliant.nielsenmedia.com (reliant.nielsenmedia.com [205.129.32.15]) by space.twc.de (8.8.7/8.8.7) with ESMTP id WAA14327 for ; Sat, 31 Jul 1999 22:18:59 +0200 Received: from nielsenmedia.com (ibis.nielsenmedia.com [10.9.42.160]) by reliant.nielsenmedia.com (8.9.3/8.9.3) with ESMTP id QAA20569 for ; Sat, 31 Jul 1999 16:19:33 -0400 (EDT) Received: from spackle ([10.9.252.29]) by nielsenmedia.com (8.8.7/8.6.9) with SMTP id QAA15682 for ; Sat, 31 Jul 1999 16:19:32 -0400 (EDT) From: Mike Wohlgemuth To: Subject: aRts experiences Date: Sat, 31 Jul 1999 16:17:15 -0400 Message-ID: <01D4D419B1A4D111A30400805FE65B130248AE76@nmrusdunsx1.nielsenmedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO X-Status: A Content-Length: 1435 Lines: 48 I've been trying to get 0.3.1 working under Red Hat 6.0, and have come to a dead end. Here is my system: Linux Kernel 2.2.5 KDE 1.1.1pre2 QT 1.44 mico 2.2.7 egcs 1.1.2 audiofile 0.1.7 aRts 0.3.1 with arts-0.3.1-mico-2.2.7.patch After applying the patch, I had to add #include to artsshell.cc in order to get it to compile. Red Hat seemed to be blowing off my LD_LIBRARY_PATH, so I had to add /usr/local/mico/orb to /etc/ld.so.conf before I could get synth_server to run. So far, so good. Next, I tried to open and play stereobeep.arts. No sound came out of my Sound Blaster 16. The synth_server console said: Synth_PLAY: audioinit: channels is 2 sound_realtime : Bad file descriptor SNDCTL_DSP_SETFMT: Bad file descriptor It looks to me like this must be coming from sound_init in sound-linux.c, but knowing very little about how sound works in Linux, I haven't gotten any further than that. Next, I tried replacing the play module with a fileplay module in stereobeep.arts. This ran without any messages in the synth_server console, and created /tmp/arts.wav, but the file, while it seemed to be a valid wav file, contained no actual sounds. So I guess I have a few questions: Should my SB16 work with aRts, or do I need a better sound card? Is my /dev/dsp screwed up? Is there a known issue that will keep aRts from actually outputting any sound, either to /dev/dsp or to /tmp/arts.wav? Thanks Woogie From owner-arts@space.twc.de Sun Aug 1 02:19:57 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA14737 for arts-list; Sun, 1 Aug 1999 01:34:36 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from ghs.ssd.k12.wa.us (pdavis@[216.186.55.11]) by space.twc.de (8.8.7/8.8.7) with ESMTP id BAA14734 for ; Sun, 1 Aug 1999 01:34:25 +0200 Received: from localhost (pdavis@localhost) by ghs.ssd.k12.wa.us (8.9.3/8.8.7) with ESMTP id QAA26884 for ; Sat, 31 Jul 1999 16:40:25 -0700 Date: Sat, 31 Jul 1999 16:40:25 -0700 (PDT) From: Peter Davis To: arts@space.twc.de Subject: Re: aRts experiences In-Reply-To: <01D4D419B1A4D111A30400805FE65B130248AE76@nmrusdunsx1.nielsenmedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2542 Lines: 83 You must have done something wrong, becuase that is completely different than what happened to me on the exact same system. First off I didn't have to add the unistd.h, and I didn't have any problems with libraries. What I did have, though, was a segfault right after the server starts (see past message(s)). , , /( )` \ __ / | /- _ `-/ ' (/\/ \ \ /\ / / | ` \ O O ) | `-^--'`< ' (_.) _ ) / `.___/` / `-----' / <----. __ / __ \ <----|====O)))==) \) /====PeTeR-DaViS <----' `--' `.__,' \ | pdavis@ | \ghs.ssd/ ____( (.k12/ ______ ,' ,----'.wa| \ `--{_*_*_*_.us) \/ (if you don't have a fixed-width font that may turn out a little screwy) On Sat, 31 Jul 1999, Mike Wohlgemuth wrote: > I've been trying to get 0.3.1 working under Red Hat 6.0, and have come to a > dead end. Here is my system: > > Linux Kernel 2.2.5 > KDE 1.1.1pre2 > QT 1.44 > mico 2.2.7 > egcs 1.1.2 > audiofile 0.1.7 > > aRts 0.3.1 with arts-0.3.1-mico-2.2.7.patch > > After applying the patch, I had to add > > #include > > to artsshell.cc in order to get it to compile. > > Red Hat seemed to be blowing off my LD_LIBRARY_PATH, so I had to add > /usr/local/mico/orb to /etc/ld.so.conf before I could get synth_server to > run. > > So far, so good. Next, I tried to open and play stereobeep.arts. No sound > came out of my Sound Blaster 16. The synth_server console said: > > Synth_PLAY: audioinit: channels is 2 > sound_realtime > : Bad file descriptor > SNDCTL_DSP_SETFMT: Bad file descriptor > > It looks to me like this must be coming from sound_init in sound-linux.c, > but knowing very little about how sound works in Linux, I haven't gotten any > further than that. > > Next, I tried replacing the play module with a fileplay module in > stereobeep.arts. This ran without any messages in the synth_server console, > and created /tmp/arts.wav, but the file, while it seemed to be a valid wav > file, contained no actual sounds. > > So I guess I have a few questions: > > Should my SB16 work with aRts, or do I need a better sound card? Is my > /dev/dsp screwed up? Is there a known issue that will keep aRts from > actually outputting any sound, either to /dev/dsp or to /tmp/arts.wav? > > Thanks > Woogie > > From owner-arts@space.twc.de Sun Jul 25 04:29:06 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id EAA27139 for arts-list; Sun, 25 Jul 1999 04:28:55 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hotmail.com (f12.hotmail.com [207.82.250.23]) by space.twc.de (8.8.7/8.8.7) with SMTP id EAA27136 for ; Sun, 25 Jul 1999 04:28:49 +0200 Received: (qmail 66321 invoked by uid 0); 17 Jul 1999 10:18:27 -0000 Message-ID: <19990717101827.66320.qmail@hotmail.com> Received: from 200.38.133.18 by www.hotmail.com with HTTP; Sat, 17 Jul 1999 03:18:10 PDT X-Originating-IP: [200.38.133.18] From: "Ernesto Cedillo Arias" To: arts@space.twc.de Subject: Problems compiling Arts Date: Sat, 17 Jul 1999 05:18:10 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 22258 Lines: 496 Hello Could somebody help me? I am desperatly trying to compile arts but it is not succeding. My system is: PenitumII, 266 Mhz, 64MB Redhat 6.0 base Glibc 2.1.1 mico 2.2.5 audiofile 0.1.7 (the 0.1.6 with RedHat doesn't work) qt 1.44 egcs,c++ 1.1.2 This is what I all: {ernst@nemesis arts-0.3.1}# make make all-recursive make[1]: Entering directory `/tmp/test/arts-0.3.1' Making all in src make[2]: Entering directory `/tmp/test/arts-0.3.1/src' Making all in synthesizer make[3]: Entering directory `/tmp/test/arts-0.3.1/src/synthesizer' /usr/local/bin/idl --query-server-for-narrow synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth.cc /usr/local/bin/idl --query-server-for-narrow midibus.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midibus.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_server.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synth_impl.cc synth_impl.cc: In method `Synthesizer_impl::Synthesizer_impl()': synth_impl.cc:79: warning: int format, long int arg (arg 2) synth_impl.cc: In method `bool Synthesizer_impl::Exec()': synth_impl.cc:158: warning: ANSI C++ forbids implicit conversion from `void *' in initialization synth_impl.cc:176: warning: comparison between signed and unsigned synth_impl.cc:178: warning: comparison between signed and unsigned synth_impl.cc:179: warning: comparison between signed and unsigned synth_impl.cc: In method `MICO_Long Synthesizer_impl::createStructure1(class Arts::StructureDesc *)': synth_impl.cc:402: warning: int format, long int arg (arg 2) synth_impl.cc: In method `void Synthesizer_impl::removeDynamicConnections(class SynthModule *)': synth_impl.cc:604: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::createModule(MICO_Long, class Arts::ModuleDesc *)': synth_impl.cc:837: warning: unused variable `long int foundnr' synth_impl.cc:873: warning: control reaches end of non-void function `Synthesizer_impl::createModule(MICO_Long , Arts::ModuleDesc *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::remoteConnectModules(MICO_Long, MICO_Long, const clas s SequenceTmpl,0> &, class Arts::ArtsServer *)': synth_impl.cc:895: warning: comparison between signed and unsigned synth_impl.cc:902: warning: comparison between signed and unsigned synth_impl.cc:921: warning: control reaches end of non-void function `Synthesizer_impl::remoteConnectModules(M ICO_Long, MICO_Long, const SequenceTmpl,0> &, Arts::ArtsServer *)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::localConnectModules(MICO_Long)': synth_impl.cc:925: warning: `return' with no value, in function returning non-void synth_impl.cc:939: warning: comparison between signed and unsigned synth_impl.cc:952: warning: comparison between signed and unsigned synth_impl.cc:972: warning: control reaches end of non-void function `Synthesizer_impl::localConnectModules(MI CO_Long)' synth_impl.cc: In method `MICO_Boolean Synthesizer_impl::finalizeModules(MICO_Long)': synth_impl.cc:976: warning: `return' with no value, in function returning non-void synth_impl.cc:999: warning: control reaches end of non-void function `Synthesizer_impl::finalizeModules(MICO_L ong)' g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c synthmodule.cc synthmodule.cc:26: warning: static member `SynthConnection::instances' re-declared as static synthmodule.cc:29: warning: static member `SynthBuffer::instances' re-declared as static synthmodule.cc:32: warning: static member `SynthBuffer::allbytes' re-declared as static synthmodule.cc: In method `void SynthModule::assignInConn(class SynthConnection *)': synthmodule.cc:140: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:145: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthModule::assignOutConn(class SynthConnection *)': synthmodule.cc:150: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc:155: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `long int SynthModule::request(long int)': synthmodule.cc:215: warning: comparison between signed and unsigned synthmodule.cc: In method `long int SynthModule::calc(long int)': synthmodule.cc:275: warning: comparison between signed and unsigned synthmodule.cc:294: warning: comparison between signed and unsigned synthmodule.cc:306: warning: comparison between signed and unsigned synthmodule.cc:317: warning: comparison between signed and unsigned synthmodule.cc:326: warning: comparison between signed and unsigned synthmodule.cc:346: warning: comparison between signed and unsigned synthmodule.cc:352: warning: comparison between signed and unsigned synthmodule.cc:364: warning: comparison between signed and unsigned synthmodule.cc:371: warning: comparison between signed and unsigned synthmodule.cc: In method `SynthBuffer::SynthBuffer(float, long unsigned int)': synthmodule.cc:398: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::connectToSource(class SynthConnection *)': synthmodule.cc:457: warning: ANSI C++ forbids implicit conversion from `void *' in assignment synthmodule.cc: In method `void SynthConnection::disconnectFromSource(class SynthConnection *)': synthmodule.cc:471: warning: comparison between signed and unsigned synthmodule.cc:475: warning: ANSI C++ forbids implicit conversion from `void *' in assignment g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c ioevent.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c modules.cc modules.cc:46: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:46: warning: making `INVALUE' static modules.cc:47: warning: ANSI C++ forbids initialization of const member `CAPACITY_B' modules.cc:47: warning: making `CAPACITY_B' static modules.cc:48: warning: ANSI C++ forbids initialization of const member `CAPACITY_F' modules.cc:48: warning: making `CAPACITY_F' static modules.cc:50: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:50: warning: making `OUTVALUE' static modules.cc:189: warning: ANSI C++ forbids initialization of const member `INVALUE1' modules.cc:189: warning: making `INVALUE1' static modules.cc:190: warning: ANSI C++ forbids initialization of const member `INVALUE2' modules.cc:190: warning: making `INVALUE2' static modules.cc:191: warning: ANSI C++ forbids initialization of const member `PERCENTAGE' modules.cc:191: warning: making `PERCENTAGE' static modules.cc:192: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:192: warning: making `OUTVALUE' static modules.cc:227: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:227: warning: making `INVALUE' static modules.cc:228: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:228: warning: making `POS' static modules.cc:229: warning: ANSI C++ forbids initialization of const member `TOP' modules.cc:229: warning: making `TOP' static modules.cc:230: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:230: warning: making `OUTVALUE' static modules.cc:277: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:277: warning: making `INVALUE' static modules.cc:278: warning: ANSI C++ forbids initialization of const member `FACTOR' modules.cc:278: warning: making `FACTOR' static modules.cc:279: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:279: warning: making `OUTVALUE' static modules.cc:300: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:300: warning: making `INVALUE' static modules.cc:301: warning: ANSI C++ forbids initialization of const member `ADDIT' modules.cc:301: warning: making `ADDIT' static modules.cc:302: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:302: warning: making `OUTVALUE' static modules.cc:324: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:324: warning: making `INVALUE' static modules.cc:325: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:325: warning: making `TIME' static modules.cc:326: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:326: warning: making `OUTVALUE' static modules.cc:384: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:384: warning: making `FREQUENCY' static modules.cc:385: warning: ANSI C++ forbids initialization of const member `MODULATOR' modules.cc:385: warning: making `MODULATOR' static modules.cc:386: warning: ANSI C++ forbids initialization of const member `MODLEVEL' modules.cc:386: warning: making `MODLEVEL' static modules.cc:387: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:387: warning: making `POSITION' static modules.cc:411: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:411: warning: making `FREQUENCY' static modules.cc:412: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:412: warning: making `POSITION' static modules.cc:523: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:523: warning: making `POSITION' static modules.cc:524: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:524: warning: making `OUTVALUE' static modules.cc:554: warning: ANSI C++ forbids initialization of const member `POSITION' modules.cc:554: warning: making `POSITION' static modules.cc:555: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:555: warning: making `FREQUENCY' static modules.cc:556: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:556: warning: making `OUTVALUE' static modules.cc:593: warning: ANSI C++ forbids initialization of const member `SPEED' modules.cc:593: warning: making `SPEED' static modules.cc:594: warning: ANSI C++ forbids initialization of const member `FREQUENCY' modules.cc:594: warning: making `FREQUENCY' static modules.cc:595: warning: ANSI C++ forbids initialization of const member `POS' modules.cc:595: warning: making `POS' static modules.cc:668: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:668: warning: making `INVALUE' static modules.cc:703: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:703: warning: making `INVALUE_L' static modules.cc:704: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:704: warning: making `INVALUE_R' static modules.cc:705: warning: ANSI C++ forbids initialization of const member `CHANNELS' modules.cc:705: warning: making `CHANNELS' static modules.cc:880: warning: ANSI C++ forbids initialization of const member `INVALUE_L' modules.cc:880: warning: making `INVALUE_L' static modules.cc:881: warning: ANSI C++ forbids initialization of const member `INVALUE_R' modules.cc:881: warning: making `INVALUE_R' static modules.cc:985: warning: ANSI C++ forbids initialization of const member `ACTIVE' modules.cc:985: warning: making `ACTIVE' static modules.cc:986: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:986: warning: making `INVALUE' static modules.cc:987: warning: ANSI C++ forbids initialization of const member `ATTACK' modules.cc:987: warning: making `ATTACK' static modules.cc:988: warning: ANSI C++ forbids initialization of const member `DECAY' modules.cc:988: warning: making `DECAY' static modules.cc:989: warning: ANSI C++ forbids initialization of const member `SUSTAIN' modules.cc:989: warning: making `SUSTAIN' static modules.cc:990: warning: ANSI C++ forbids initialization of const member `RELEASE' modules.cc:990: warning: making `RELEASE' static modules.cc:993: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:993: warning: making `OUTVALUE' static modules.cc:994: warning: ANSI C++ forbids initialization of const member `DONE' modules.cc:994: warning: making `DONE' static modules.cc:997: warning: ANSI C++ forbids initialization of const member `NOOUT' modules.cc:997: warning: making `NOOUT' static modules.cc:1164: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1164: warning: making `INVALUE' static modules.cc:1183: warning: ANSI C++ forbids initialization of const member `READY' modules.cc:1183: warning: making `READY' static modules.cc:1209: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1209: warning: making `INVALUE' static modules.cc:1210: warning: ANSI C++ forbids initialization of const member `TIME' modules.cc:1210: warning: making `TIME' static modules.cc:1211: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1211: warning: making `OUTVALUE' static modules.cc:1288: warning: ANSI C++ forbids initialization of const member `INVALUE' modules.cc:1288: warning: making `INVALUE' static modules.cc:1289: warning: ANSI C++ forbids initialization of const member `INSCALE' modules.cc:1289: warning: making `INSCALE' static modules.cc:1290: warning: ANSI C++ forbids initialization of const member `OUTVALUE' modules.cc:1290: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c sound-linux.c gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c utils.c g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c midi.cc In file included from midi.cc:23: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static midi.cc:152: warning: ANSI C++ forbids initialization of const member `CHANNEL' midi.cc:152: warning: making `CHANNEL' static midi.cc:153: warning: ANSI C++ forbids initialization of const member `MAXVOICES' midi.cc:153: warning: making `MAXVOICES' static midi.cc:154: warning: ANSI C++ forbids initialization of const member `COUNT' midi.cc:154: warning: making `COUNT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c structures.cc structures.cc: In method `MICO_Long ModuleDesc_impl::Width()': structures.cc:293: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long ModuleDesc_impl::Height()': structures.cc:305: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Width()': structures.cc:330: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `MICO_Long StructureDesc_impl::Height()': structures.cc:342: warning: `MICO_Long retval' might be used uninitialized in this function structures.cc: In method `void StructureDesc_impl::moveStructurePortDesc(class Arts::StructurePortDesc *, long int)': structures.cc:992: warning: comparison between signed and unsigned g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c artsobject.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c bus.cc bus.cc:154: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:154: warning: making `LEFT' static bus.cc:155: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:155: warning: making `RIGHT' static bus.cc:156: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:156: warning: making `BUSNAME' static bus.cc:189: warning: ANSI C++ forbids initialization of const member `CLIENTS' bus.cc:189: warning: making `CLIENTS' static bus.cc:190: warning: ANSI C++ forbids initialization of const member `BUSNAME' bus.cc:190: warning: making `BUSNAME' static bus.cc:191: warning: ANSI C++ forbids initialization of const member `LEFT' bus.cc:191: warning: making `LEFT' static bus.cc:192: warning: ANSI C++ forbids initialization of const member `RIGHT' bus.cc:192: warning: making `RIGHT' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c cache.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c wav.cc wav.cc:130: warning: ANSI C++ forbids initialization of const member `LEFT' wav.cc:130: warning: making `LEFT' static wav.cc:131: warning: ANSI C++ forbids initialization of const member `RIGHT' wav.cc:131: warning: making `RIGHT' static wav.cc:132: warning: ANSI C++ forbids initialization of const member `DONE' wav.cc:132: warning: making `DONE' static wav.cc:133: warning: ANSI C++ forbids initialization of const member `FILENAME' wav.cc:133: warning: making `FILENAME' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c interfaces.cc In file included from interfaces.cc:22: interfaces.h:27: warning: ANSI C++ forbids initialization of const member `FREQUENCY' interfaces.h:27: warning: making `FREQUENCY' static interfaces.h:28: warning: ANSI C++ forbids initialization of const member `VELOCITY' interfaces.h:28: warning: making `VELOCITY' static interfaces.h:29: warning: ANSI C++ forbids initialization of const member `PRESSED' interfaces.h:29: warning: making `PRESSED' static g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music.cc music.cc:32: warning: ANSI C++ forbids initialization of const member `INVALUE' music.cc:32: warning: making `INVALUE' static music.cc:33: warning: ANSI C++ forbids initialization of const member `FREQUENCY' music.cc:33: warning: making `FREQUENCY' static music.cc:35: warning: ANSI C++ forbids initialization of const member `OUTVALUE' music.cc:35: warning: making `OUTVALUE' static gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11 R6/include -O2 -Wall -c music_orig.c ++ -I. -I../../include -O -fno-exceptions -fexceptions -O0 -I/usr/local/include -c NamingClient.cc -o Nam g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c receiver_impl.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c expand.cc /bin/sh ../../libtool --mode=link g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile g++ -O2 -Wall -L/usr/local/kde/lib -L/usr/X11R6/lib -L/usr/local/lib -o synth_server.bin synth.o midibus.o synth_server.o synth_impl.o synthmodule.o ioevent.o modules.o sound-linux.o utils.o midi.o structures.o artsobject.o bus.o cache.o wav.o interfaces.o music.o music_orig.o debug.o resources.o mbroker_impl.o execrequest.o receiver_impl.o expand.o -lmico2.2.5 -ldl -laudiofile make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/synthesizer' Making all in shellutils make[3]: Entering directory `/tmp/test/arts-0.3.1/src/shellutils' /usr/local/bin/idl ../synthesizer/synth.idl g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c synth.cc g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/kde/include -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c artsshell.cc artsshell.cc: In function `int main(int, char **)': artsshell.cc:44: warning: implicit declaration of function `int getopt(...)' artsshell.cc:48: `optarg' undeclared (first use this function) artsshell.cc:48: (Each undeclared identifier is reported only once artsshell.cc:48: for each function it appears in.) artsshell.cc:61: confused by earlier errors, bailing out make[3]: *** [artsshell.o] Error 1 make[3]: Leaving directory `/tmp/test/arts-0.3.1/src/shellutils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/test/arts-0.3.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/test/arts-0.3.1' make: *** [all-recursive-am] Error 2 [ernst@nemesis arts-0.3.1]# On the other hand I compiled mico2.2.7 and then atttempted to patch arts.0.3.1 source, but I got rejctions. Is there any other patch I could use? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-arts@space.twc.de Mon Jul 26 20:34:35 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA07446 for arts-list; Mon, 26 Jul 1999 20:34:18 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from ghs.ssd.k12.wa.us (root@[216.186.55.11]) by space.twc.de (8.8.7/8.8.7) with ESMTP id UAA07438 for ; Mon, 26 Jul 1999 20:32:56 +0200 Received: from ghs.ssd.k12.wa.us (1Cust213.tnt4.krk1.da.uu.net [208.254.1.213]) by ghs.ssd.k12.wa.us (8.9.3/8.8.7) with SMTP id LAA10424 for ; Mon, 26 Jul 1999 11:38:10 -0700 Message-ID: <379CA993.281C8AC8@ghs.ssd.k12.wa.us> Date: Mon, 26 Jul 1999 18:31:47 +0000 From: Peter Davis X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Re: Problems with RH6 References: <379ADDBB.1C10942@ghs.ssd.k12.wa.us> <19990726134000.23490@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: RO X-Status: A Content-Length: 3134 Lines: 87 Stefan Westerfeld wrote: > Well, ok. Debugging these errors of course could have been possible if > you posted them, but if it works with 1.7 thats fine, too. I am using > 0.1.6 on debian 2.1, but I had to hand edit one header file, which had > two closing brackets if __cplusplus was defined. Yes I had that problem also, but the big problem was that there were about 20 errors when linking wav.o saying basically that it couldn't find functions in the audiofile library. But that doesn't matter, because an upgrade to 1.7 worked for me. > > From what you tell, it sounds like a kernel/driver problem. Are you sure > you have set up DMA and IRQ and that stuff correctly? This usually gives > ugly problems when not done properly. > > Try looking in /var/log/messages if there are some unusual error messages. > > Your problems could also be card specific. I am for instance using linux > 2.2.9 with an AWE64 (using the SB16 driver), and it works really fine. As far as I can tell everything is set up fine (since it works perfectly with other programs). My card is a brand new SB PCI 128, which is (i guess) plug-n-play because the 'sndconfig' program that comes with RH6 to set up the correct kernel modules doesn't even ask for interrupts or anything. Also, today I ran gdb to see if I could find the location of the segfault: here is what I got: -----------------START CUT--------------------- ... (basic gdb copyright info) (gdb) run Starting program: /usr/bin/artsbuilder QT: gdb: -nograb added to command-line options. Use the -dograb option to enforce grabbing. [New Thread 1169] [New Thread 1160] [New Thread 1170] AR UP... publishing module Gui_SLIDER: constructor - module created - not null one GUIServer object freed => total 0 ArtsObjects alive Program recieved signal SIGSEGV, Segmentation fault. 0x406d1626 in _fini () -----------END CUT------------------------------ This makes me think that it is a problem with QT (RH6 comes with version 1.44-6) more than a problem with the soundcard. Since '_fini ()' looks to me like the crash comes when (one of) the programs (or threads) is trying to quit, it could be that the different behaviour if the soundcard is in use comes from the program trying to bail out when it can't initialize properly. I will try to upgrade QT and see what happens. -- How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say "I told you so" when it doesn't work. , , /( )` \ \__ / | /- _ `-/ ' (/\/ \ \ /\ / / | ` \ O O ) | `-^--'`< ' (_.) _ ) / `.___/` / `-----' / <----. __ / __ \ <----|====O)))==) \) /====PeTeR-DaViS <----' `--' `.__,' \ | pdavis@ | \ghs.ssd/ ____( (.k12/ \______ ,' ,----'.wa| \ `--{_*_*_*_.us) \/ (if you don't have a fixed-width font that may turn out a little screwy) From owner-arts@space.twc.de Mon Aug 2 18:19:57 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id JAA16826 for arts-list; Mon, 2 Aug 1999 09:20:34 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from bastuba.partitur.se (bastuba.partitur.se [193.219.246.194]) by space.twc.de (8.8.7/8.8.7) with ESMTP id JAA16823 for ; Mon, 2 Aug 1999 09:20:23 +0200 Received: from partitur.se (tb303.partitur.se [193.219.246.230]) by bastuba.partitur.se (8.8.8/8.8.8) with ESMTP id JAA20030 for ; Mon, 2 Aug 1999 09:21:30 +0200 (CEST) (envelope-from kudo@partitur.se) Message-ID: <37A546F9.C7B59748@partitur.se> Date: Mon, 02 Aug 1999 09:21:29 +0200 From: Patrik Kudo Organization: Partitur Informationsteknik X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: sv,en MIME-Version: 1.0 To: arts@space.twc.de Subject: aRts on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 259 Lines: 9 Hi, Has anyone had any experience compiling aRts on FreeBSD? I gave it a shot last night but got quite a few errors that I had to fix. Haven't got through everything yet, so I thougt I'd ask before I put any more time on the project... Regards, Patrik Kudo From owner-arts@space.twc.de Mon Aug 2 19:20:04 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA20476 for arts-list; Mon, 2 Aug 1999 19:20:02 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id TAA20471; Mon, 2 Aug 1999 19:19:59 +0200 Message-ID: <19990802191959.00941@space.twc.de> Date: Mon, 2 Aug 1999 19:19:59 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with RH6 References: <379ADDBB.1C10942@ghs.ssd.k12.wa.us> <19990726134000.23490@space.twc.de> <379CA993.281C8AC8@ghs.ssd.k12.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <379CA993.281C8AC8@ghs.ssd.k12.wa.us>; from Peter Davis on Mon, Jul 26, 1999 at 06:31:47PM +0000 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2921 Lines: 77 Hi! On Mon, Jul 26, 1999 at 06:31:47PM +0000, Peter Davis wrote: > Stefan Westerfeld wrote: > > From what you tell, it sounds like a kernel/driver problem. Are you sure > > you have set up DMA and IRQ and that stuff correctly? This usually gives > > ugly problems when not done properly. > > > > Try looking in /var/log/messages if there are some unusual error messages. > > > > Your problems could also be card specific. I am for instance using linux > > 2.2.9 with an AWE64 (using the SB16 driver), and it works really fine. > > As far as I can tell everything is set up fine (since it works > perfectly with other programs). My card is a brand new SB PCI 128, > which is (i guess) plug-n-play because the 'sndconfig' program that > comes with RH6 to set up the correct kernel modules doesn't even ask > for interrupts or anything. > > Also, today I ran gdb to see if I could find the location of the > segfault: here is what I got: > > -----------------START CUT--------------------- > ... (basic gdb copyright info) > > (gdb) run > Starting program: /usr/bin/artsbuilder > QT: gdb: -nograb added to command-line options. > Use the -dograb option to enforce grabbing. > [New Thread 1169] > [New Thread 1160] > [New Thread 1170] > AR UP... > publishing module Gui_SLIDER: > constructor > - module created > - not null > one GUIServer object freed => total 0 ArtsObjects alive > > Program recieved signal SIGSEGV, Segmentation fault. > 0x406d1626 in _fini () > -----------END CUT------------------------------ > > This makes me think that it is a problem with QT (RH6 comes with > version 1.44-6) more than a problem with the soundcard. Since '_fini > ()' looks to me like the crash comes when (one of) the programs (or > threads) is trying to quit, it could be that the different behaviour > if the soundcard is in use comes from the program trying to bail out > when it can't initialize properly. Hi! First of all: try upgrading to arts-0.3.2 which is available at the webpage and see if the problem is still there. Then: From what I read, I suppose that artsbuilder is crashing? You can start them seperately, you can for instance start synth_server in one terminal window, and use artsshell -f stereobeep.arts -e in another. (stereobeep.arts is in the examples dir) So you can test if the synth_server is ok even when artsbuilder might be broken. Also, it would be helpful if you compile artsbuilder with -g then (if artsbuilder is the problem), and make a backtrace (bt in gdb). If synth_server is the program which segfaults, try the same with synth_server. If you suppose its a Qt & Threading issue, you can compile artsbuilder entierly without threading. Remove "#define THREADED_ROUTING" from autorouter.h and recompile. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Aug 2 19:29:55 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA20522 for arts-list; Mon, 2 Aug 1999 19:29:54 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id TAA20517; Mon, 2 Aug 1999 19:29:51 +0200 Message-ID: <19990802192950.07428@space.twc.de> Date: Mon, 2 Aug 1999 19:29:50 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: aRts experiences References: <01D4D419B1A4D111A30400805FE65B130248AE76@nmrusdunsx1.nielsenmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <01D4D419B1A4D111A30400805FE65B130248AE76@nmrusdunsx1.nielsenmedia.com>; from Mike Wohlgemuth on Sat, Jul 31, 1999 at 04:17:15PM -0400 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2456 Lines: 80 Hi! On Sat, Jul 31, 1999 at 04:17:15PM -0400, Mike Wohlgemuth wrote: > I've been trying to get 0.3.1 working under Red Hat 6.0, and have come to a > dead end. Here is my system: > > Linux Kernel 2.2.5 > KDE 1.1.1pre2 > QT 1.44 > mico 2.2.7 > egcs 1.1.2 > audiofile 0.1.7 > > aRts 0.3.1 with arts-0.3.1-mico-2.2.7.patch > > After applying the patch, I had to add > > #include > > to artsshell.cc in order to get it to compile. > > Red Hat seemed to be blowing off my LD_LIBRARY_PATH, so I had to add > /usr/local/mico/orb to /etc/ld.so.conf before I could get synth_server to > run. Fine so far. You > > So far, so good. Next, I tried to open and play stereobeep.arts. No sound > came out of my Sound Blaster 16. The synth_server console said: > > Synth_PLAY: audioinit: channels is 2 > sound_realtime > : Bad file descriptor > SNDCTL_DSP_SETFMT: Bad file descriptor > > It looks to me like this must be coming from sound_init in sound-linux.c, > but knowing very little about how sound works in Linux, I haven't gotten any > further than that. It looks like opening /dev/dsp fails. Go to modules.cc, and add assert(audiofd > 0); after the line audiofd = sound_open(); there. If this assertion then fails, you have a more basic problem with sound, like - no sound driver installed - sound driver not working - user has no permission to open /dev/dsp or similar. Do other programs that require sound work? > > Next, I tried replacing the play module with a fileplay module in > stereobeep.arts. This ran without any messages in the synth_server console, > and created /tmp/arts.wav, but the file, while it seemed to be a valid wav > file, contained no actual sounds. Thats the normal behaviour, since the synchronization and scheduling of arts depends on having /dev/dsp opened. That means, without Synth_PLAY module, no calculations are done. > So I guess I have a few questions: > > Should my SB16 work with aRts, or do I need a better sound card? Is my > /dev/dsp screwed up? Is there a known issue that will keep aRts from > actually outputting any sound, either to /dev/dsp or to /tmp/arts.wav? SB16 should be fine. Also my recommendation is to upgrade aRts to 0.3.2 (now that it is out), but your problem doesn't look version specific. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Aug 2 19:33:52 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA20547 for arts-list; Mon, 2 Aug 1999 19:33:51 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (root@server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA20544 for ; Mon, 2 Aug 1999 19:33:47 +0200 Received: from rhein-main.netsurf.de (root@dialin34.rhein-main.netsurf.de [194.163.193.34]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id TAA02509 for ; Mon, 2 Aug 1999 19:34:55 +0200 Message-ID: <37A5D47F.2DFD6CEA@rhein-main.netsurf.de> Date: Mon, 02 Aug 1999 19:25:20 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: webpage update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 632 Lines: 18 hi! the webpage is now updated, you can download download the new arts release now from the german website, the american mirror will be up to date hopefully soon. sorry for the delay, i was not at home the last days. cu <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Tue Aug 3 06:32:33 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id GAA21575 for arts-list; Tue, 3 Aug 1999 06:32:29 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [194.77.97.10]) by space.twc.de (8.8.7/8.8.7) with ESMTP id GAA21572 for ; Tue, 3 Aug 1999 06:32:24 +0200 Received: from deepthought.42.de (root@hs2-113.handshake.de [194.77.98.113]) by hs-gate.handshake.de (8.9.3/8.9.3) with ESMTP id GAA11682 for ; Tue, 3 Aug 1999 06:33:08 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by deepthought.42.de (8.9.3/8.9.3) id GAA00541 for arts@space.twc.de; Tue, 3 Aug 1999 06:23:59 +0200 From: Adrian Krebs Organization: Handshake e.V. To: arts@space.twc.de Subject: remove Date: Tue, 3 Aug 1999 06:23:03 +0200 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain References: <19990802191959.00941@space.twc.de> MIME-Version: 1.0 Message-Id: <99080306232502.00465@deepthought> Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 0 Lines: 0 From owner-arts@space.twc.de Tue Aug 3 18:52:25 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA25030 for arts-list; Tue, 3 Aug 1999 18:50:51 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from reliant.nielsenmedia.com (reliant.nielsenmedia.com [205.129.32.15]) by space.twc.de (8.8.7/8.8.7) with ESMTP id SAA25027 for ; Tue, 3 Aug 1999 18:50:43 +0200 Received: from nielsenmedia.com (ibis.nielsenmedia.com [10.9.42.160]) by reliant.nielsenmedia.com (8.9.3/8.9.3) with ESMTP id MAA16702 for ; Tue, 3 Aug 1999 12:51:20 -0400 (EDT) Received: from spackle (dhcp40-30.nielsenmedia.com [10.9.40.30]) by nielsenmedia.com (8.8.7/8.6.9) with SMTP id MAA22600 for ; Tue, 3 Aug 1999 12:51:19 -0400 (EDT) From: Mike Wohlgemuth To: Subject: RE: aRts experiences Date: Tue, 3 Aug 1999 12:49:04 -0400 Message-ID: <01D4D419B1A4D111A30400805FE65B130248AE7D@nmrusdunsx1.nielsenmedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <19990802192950.07428@space.twc.de> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 852 Lines: 28 > -----Original Message----- > From: Stefan Westerfeld [mailto:stefan@space.twc.de] > > It looks like opening /dev/dsp fails. Go to modules.cc, and add > > assert(audiofd > 0); > > after the line > > audiofd = sound_open(); > > there. If this assertion then fails, you have a more basic > problem with > sound, like > > - no sound driver installed > - sound driver not working > - user has no permission to open /dev/dsp > > or similar. Do other programs that require sound work? I added the line, and sure enough, the assertion failed. I'm not entirely sure what was happening, but /dev/dsp was definitely locked by some other app. I ended up rebooting the machine, and trying it again before running anything that would use the device. Everything worked perfectly, and I haven't had the problem since. Thanks a bunch for the help. Woogie From owner-arts@space.twc.de Sat Aug 21 17:26:15 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id RAA21367 for arts-list; Sat, 21 Aug 1999 17:25:38 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id RAA21362; Sat, 21 Aug 1999 17:25:36 +0200 Message-ID: <19990821172536.50393@space.twc.de> Date: Sat, 21 Aug 1999 17:25:36 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: aRts & the GUI challenge - call for aRtists Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 5876 Lines: 124 Hi! So that's it - we need graphics artists when we want to have a nice looking GUI. Some code is there - but knowing what it should look/work like would be a good idea before proceeding. Well - I've tried to write together the what/why/hows in a nice "call for aRtists", it got published on LinuxToday yesterday ;) ... so here's the text, and perhaps you can help, or find a place to publish this as well. Cu... Stefan ============================================================================ aRts & the GUI challenge - call for aRtists ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introduction Arts (http://linux.twc.de/arts) is a virtual analog synthesizer. But it is not one of the synthesizers that come with one method of creating sounds that is hard wired. Rather, aRts allows you to build your own synthesizer out of little components. So aRts is more a set of building blocks, where everybody can use to build his private house from. Just that you are building virtual studios and other audio technology, not houses. Still, something is mostly missing: while aRts is doing a good job when building the interior of the devices (such as which signals are routed what way, and which effects are processed when and how), it is somewhat primitive in surface/user interface design. User interfaces are of course all that turning buttons, sliders, push buttons, etc. you find for instance on the front panel of a mixer. But they are also flashing leds, equalizers, scopes and LCD displays. And of course they should allow putting labels on that boxes, so that they are not only nice to look at, but also easy to understand. So the GUI challenge for aRts is: Which components do we need for building intiutive and pretty interfaces to any of the devices that can be modelled with aRts. Let me try to explain what I mean in an example. You might say: well, thats easy, just let the user load an image, and put it as skin above aRts, and it will look really great, allow every idea of visual design, and be as good as the artist that does the picture is. And skins are easy to implement, look at x11amp... Well, what I would answer is: put a skin over what? Arts itself doesn't ship with buttons that are required for standard operation. A device you build with aRts (while a device may be an instrument, a mixer or an effect or whatever else) has no play, eject, rewind, etc. buttons. Arts itself has not even one button I talk about when I talk about the gui challenge. Rather, the task is to have components, with which a user can build the frontpanel to his favourite device. There is another argument against skin technology: Most of these users are not artists. Perhaps they are not even capable of painting a skin that looks nice. Still, why shouldn't they have nice GUIs? Arts should allow them to build their GUI out of predefined elements, but still, with these predefined elements they should be able to express any kind of interaction they require. So basically, aRts should even make people who are blind for artistic expression able to construct frontpanels which look good, are intuitive and easy to use. And that process should require as few action from the user as possible. While still being able to add personal touch (such as using a rather blackish style of front panel, with hard lines, or a rather soft orange style with many flashing lights). But how to proceed now? I. Design studies/"I want it to look like that"-Screenshots The idea I had was, that you first of all should install aRts and get familiar a little with it. At least you should have seen the examples. Then, try to create screenshots of the next major aRts release. Just how could it look. Try to take a nice device you could imagine in a studio. And try to paint a screenshot of how a possible frontpanel to it should be able to look when designed in aRts. But remember, that the design elements you use should be reusable. You should be able to model more than one frontpanel of your screenshot, if you take the scissors, cut it, and reuse the components. Also think of one important feature aRts has: You can build things that are to be used in other devices. For instance I could build a control panel for adjusting an ADSR envelope, and reuse it in some instruments that are using ADSR envelopes. So you don't only build front panels for complete structures, but also parts of front panels that are reusable. Well, when you have something, submit it, perhaps with a description of how it should work and what components you think make sense. If you like, have a look at how aRts reuses existing components. If your components are to be composed of simpler elements, you can also submit them directly. It might be like the aRts slider, which contains of one background pixmap, and one for the moving part. II. Components Of course, if you have an idea how a "LCD-Display" component or a "Foo-Slider" component should work & look, directly send it. The idea of the screenshot approach is to get a) ideas and b) consistent look and feel. But if you think you just want to do one or two components, do it. Submitting stuff Everything you submit will appear on the aRts webpage, that's sure. That means the URL you need to know is http://linux.twc.de/arts. Join the mailinglist as well, we'll try to discuss the different approaches there and try to get such components in aRts. And, perhaps, with the next major release, some aRts screenshot could look like yours. Cu... Stefan You can submit your screenshots/descriptions to our webpage maintainer Harald Lapp . Also feel free to discuss everything you like on the mailing list or with me. -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Aug 21 19:30:52 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA21780 for arts-list; Sat, 21 Aug 1999 19:30:35 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from lcremeans.erols.com (lee@lcremeans.erols.com [216.164.87.29]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA21777 for ; Sat, 21 Aug 1999 19:30:27 +0200 Received: (from lee@localhost) by lcremeans.erols.com (8.9.3/8.9.3) id NAA85170 for arts@space.twc.de; Sat, 21 Aug 1999 13:30:44 -0400 (EDT) (envelope-from lee) Message-ID: <19990821133044.A85064@erols.com> Date: Sat, 21 Aug 1999 13:30:44 -0400 From: Lee Cremeans To: arts@space.twc.de Subject: Patch to compile aRts on FreeBSD 3.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-OS: FreeBSD 3.0-STABLE Organization: My room? Are you crazy? :) Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1585 Lines: 32 I have a patch available to compile aRts-0.3.2 on FreeBSD 3.x. It fixes some problems with definitions (for some reason, FreeBSD defines _X in ctype.h, and that confuses the compiler when it parses structures.h; also, another file needed to include stdarg.h). Also, this fixes a bug in the realtime code that kept it from getting realtime priority on FreeBSD (the priority value was hard-coded; I changed it to get and use the system maximum for the given priority class). The patches will be posted at http://lcremeans.erols.com/~lee/arts-freebsd32.diff.gz in a few minutes. IMPORTANT NOTE ON COMPILING ARTS ON 3.2: aRts requires egcs-1.1.2. However, the default system compiler is gcc 2.7.2.x. you should install egcs-1.1.2 from the ports collection, and once this is done you *must* recompile Qt and everything dependent on it (i.e. KDE) with egcs (basically just uninstalling KDE and Qt if you have them, and going to /usr/ports/x11/kde and typing "make install CC=egcc CXX=eg++"). This is a pain, but it has to be done because the linker doesn't like linking C++ objects compiled with egcs and its libstdc++ against libraries compiled with 2.7.2.x and libstdc++ there. If you're using FreeBSD 4.0-CURRENT, this should not be a problem because egcs is the default compiler there. Also, you'll need mico to be installed from ports on either system. -lee -- +--------------------------------------------------------------------+ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on WTnet) | | lcremeans@erols.com | http://wakky.dyndns.org/~lee | From owner-arts@space.twc.de Tue Aug 31 18:20:03 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13741 for arts-list; Tue, 31 Aug 1999 18:18:51 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13736; Tue, 31 Aug 1999 18:18:49 +0200 Message-ID: <19990831181849.42637@space.twc.de> Date: Tue, 31 Aug 1999 18:18:49 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Patch to compile aRts on FreeBSD 3.2 References: <19990821133044.A85064@erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990821133044.A85064@erols.com>; from Lee Cremeans on Sat, Aug 21, 1999 at 01:30:44PM -0400 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 927 Lines: 22 Hi! On Sat, Aug 21, 1999 at 01:30:44PM -0400, Lee Cremeans wrote: > I have a patch available to compile aRts-0.3.2 on FreeBSD 3.x. It fixes some > problems with definitions (for some reason, FreeBSD defines _X in ctype.h, > and that confuses the compiler when it parses structures.h; also, another > file needed to include stdarg.h). Also, this fixes a bug in the realtime > code that kept it from getting realtime priority on FreeBSD (the priority > value was hard-coded; I changed it to get and use the system maximum for the > given priority class). > > The patches will be posted at > > http://lcremeans.erols.com/~lee/arts-freebsd32.diff.gz Ok, thats nice. I integrated your changes in arts-0.3.3, so that one should compile out-of-the-box on FreeBSD. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Tue Aug 31 18:24:00 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13770 for arts-list; Tue, 31 Aug 1999 18:24:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13765; Tue, 31 Aug 1999 18:23:58 +0200 Message-ID: <19990831182358.28199@space.twc.de> Date: Tue, 31 Aug 1999 18:23:58 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: aRts-0.3.2 released. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1754 Lines: 43 Hi! The latest and greatest aRts version, aRts-0.3.3 is now available. The most important changes are the visual mixer module, Gui_MIXER, and first steps for making aRts suitable as generic audio server (like ESD or KAudioServer, see the documentation included with the source for details). Ah, and for people that couldn't compile aRts, a statically linked binary is now available, however I wouldn't recommend it if you have other options, its HUGE (8Megs), since it includes KDE & Mico & Co. The changes from the ChangeLog: - Support for compiling aRts into one single statically linked binary - Code cleanups (warning free compilation, common files are now in the common directory and build as convenience libraries) - Gui_POTI requires one more arg for the initial value - New gui objects: Gui_LABEL, Gui_MIXER, Gui_AUDIO_MANAGER - Work on being able to be a "generic audio server" like esd and kaudioserver ; artscat is implemented and some audiomanager CORBA/TCP interface to aRts - "Bug"fixes: FreeBSD compile fixes, publishing a structure twice with different ports now works, possible setuid-permissions are dropped now, removed one bug in freeStructure - Work on changing string properties, which implies that you can use an Synth_BUS_UPLINK now and relink the target dynamically, which is required for instance for the "generic audio server stuff". - Added Synth_STD_EQUALIZER which allows - in combination with the Gui_MIXER really nice mixing desks. - synth_server[.bin] has been renamed to artsserver[.bin] Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Tue Aug 31 18:24:56 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13785 for arts-list; Tue, 31 Aug 1999 18:24:56 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id SAA13780; Tue, 31 Aug 1999 18:24:55 +0200 Message-ID: <19990831182455.42178@space.twc.de> Date: Tue, 31 Aug 1999 18:24:55 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: aRts-0.3.2 released. References: <19990831182358.28199@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990831182358.28199@space.twc.de>; from Stefan Westerfeld on Tue, Aug 31, 1999 at 06:23:58PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 317 Lines: 9 On Tue, Aug 31, 1999 at 06:23:58PM +0200, Stefan Westerfeld wrote: > The changes from the ChangeLog: > > [...] And of course its called aRts-0.3.3 now. (Wrong subject ;). -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Thu Sep 2 07:45:21 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id HAA17979 for arts-list; Thu, 2 Sep 1999 07:45:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from MailAndNews.com (mailandnews.com [206.156.199.130]) by space.twc.de (8.8.7/8.8.7) with ESMTP id HAA17976 for ; Thu, 2 Sep 1999 07:44:58 +0200 Received: from nemesis [148.233.123.159] (ollidec@mailandnews.com); Thu, 2 Sep 1999 01:43:48 -0400 X-WM-Posted-At: MailAndNews.com; Thu, 2 Sep 99 01:43:48 -0400 From: Ernesto CEDILLO-ARIAS To: arts@space.twc.de Subject: Problems compiling 0.3.3 Date: Thu, 2 Sep 1999 00:42:29 -0500 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99090200482600.01778@nemesis> Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 347 Lines: 10 Hi I have tried to compile this new fresh 0.3.3. version but I got something missing. For the building of audioman_impl.cc I get the file socketbits.h missing. Which include lib is this file belonging to? I have a Redhat 6.0 based system with kernel 2.2.11 working fine. I have succesfully compiled other KDE apps. So what is missing? Thanks From owner-arts@space.twc.de Thu Sep 2 19:52:31 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA19293 for arts-list; Thu, 2 Sep 1999 19:51:46 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id TAA19288; Thu, 2 Sep 1999 19:51:45 +0200 Message-ID: <19990902195145.22675@space.twc.de> Date: Thu, 2 Sep 1999 19:51:45 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems compiling 0.3.3 References: <99090200482600.01778@nemesis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <99090200482600.01778@nemesis>; from Ernesto CEDILLO-ARIAS on Thu, Sep 02, 1999 at 12:42:29AM -0500 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1124 Lines: 37 Hi! On Thu, Sep 02, 1999 at 12:42:29AM -0500, Ernesto CEDILLO-ARIAS wrote: > I have tried to compile this new fresh 0.3.3. version but I got > something missing. > For the building of audioman_impl.cc I get the file socketbits.h missing. > Which include lib is this file belonging to? > I have a Redhat 6.0 based system with kernel 2.2.11 working fine. I have > succesfully compiled other KDE apps. So what is missing? socketbits.h contains the "linger" structure which allows me to specify that a socket should try to send unsent (but written) data before closing for a certain amount of time. You could try to do a grep linger /usr/include/* grep linger /usr/include/sys/* grep linger /usr/include/linux/* to see where it is declared on your system. But probably, it will work if you replace #include by #include #include Please tell me what solves the problem so I can include it in the next release. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Thu Sep 2 23:47:41 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA19788 for arts-list; Thu, 2 Sep 1999 23:47:15 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from MailAndNews.com (mailandnews.com [206.156.199.130]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA19785 for ; Thu, 2 Sep 1999 23:47:11 +0200 From: ollidec@mailandnews.com Received: from nemesis [148.233.119.158] (ollidec@mailandnews.com); Thu, 2 Sep 1999 17:45:57 -0400 X-WM-Posted-At: MailAndNews.com; Thu, 2 Sep 99 17:45:57 -0400 To: arts@space.twc.de Subject: Re: Problems compiling 0.3.3 Date: Thu, 2 Sep 1999 15:49:01 -0500 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <19990902195145.22675@space.twc.de> MIME-Version: 1.0 Message-Id: <99090216455000.00617@nemesis> Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2569 Lines: 78 Hello again: On Thu, 02 Sep 1999, you wrote: > Hi! > > On Thu, Sep 02, 1999 at 12:42:29AM -0500, Ernesto CEDILLO-ARIAS wrote: > > I have tried to compile this new fresh 0.3.3. version but I got > > something missing. > > For the building of audioman_impl.cc I get the file socketbits.h missing. > > Which include lib is this file belonging to? > > I have a Redhat 6.0 based system with kernel 2.2.11 working fine. I have > > succesfully compiled other KDE apps. So what is missing? > > socketbits.h contains the "linger" structure which allows me to specify > that a socket should try to send unsent (but written) data before closing > for a certain amount of time. > > You could try to do a > > grep linger /usr/include/* > grep linger /usr/include/sys/* > grep linger /usr/include/linux/* > > to see where it is declared on your system. But probably, it will work if > you replace > > #include > > by > > #include > #include > > Please tell me what solves the problem so I can include it in the next > release. > > Cu... Stefan > -- > -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany > KDE Developer, project infos at http://space.twc.de/~stefan/kde *- I think this is the one I was looking for: [ernst@nemesis ernst]$ grep linger /usr/include/sys/* /usr/include/sys/socket.h: `struct msghdr', and `struct linger' types. */ I replaced the socketbits.h line with the ones you advise. It compiled fine except for some enigmatic warnings, here they are: audioman_impl.cc: In method `AudioManager_impl::~AudioManager_impl()': audioman_impl.cc:65: warning: implicit declaration of function `int close(...)' audioman_impl.cc: In method `void AudioManager_impl::notifyIO(int)': audioman_impl.cc:89: warning: implicit declaration of function `int write(...)' audioman_impl.cc: In method `void AudioUplink_impl::notifyIO(int)': audioman_impl.cc:304: warning: implicit declaration of function `int read(...)' autorouter.cpp: In method `void AutoRouter::thread_command_loop()': autorouter.cpp:184: warning: implicit declaration of function `int usleep(...)' Now I have this trouble I try to execute arts but nothing happened and then I got this. Should I recompile mico?? [ernst@nemesis bin]$ artsbuilder AR UP... publishing module Gui_LABEL: constructor - module created - not null one GUIServer object freed => total 0 ArtsObjects alive AR DOWN... uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0, not-completed) Aborted thanks From owner-arts@space.twc.de Fri Sep 3 12:43:25 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA21123 for arts-list; Fri, 3 Sep 1999 12:41:53 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id MAA21117; Fri, 3 Sep 1999 12:41:49 +0200 From: Stefan Westerfeld Message-Id: <199909031041.MAA21117@space.twc.de> Subject: Re: arts compile problem To: cyrwyn@nr.infi.net (Stuart Norman) Date: Fri, 3 Sep 1999 12:41:48 +0200 (CEST) Cc: arts@space.twc.de In-Reply-To: <99090219503300.18509@Cyrwyn.Leatherfaerie.nom> from "Stuart Norman" at Sep 2, 99 07:39:45 pm Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 732 Lines: 24 Hi! > When compiling arts-0.3.3, when in /src/synthesizer directory make gives this > error: wav.cc: h:21 parse error before '}' > > I'm running RedHat Linux 6.0 with updates. > > Is there a simple fix for this? I'm not a programmer. After successfully > compiling MICO-2.2.7 (yes, I disabled mini-stl) just to build this, it is a > letdown. Libaudiofile ships with a broken header file (with unbalanced brackets when __cplusplus is defined), which leads to the error you describe. To fix that, you can either go to /usr/include/aupvlist.h and remove one of the two closing brackets looking like #ifdef __cplusplus } #endif that is on line 59 on my system or upgrade libaudiofile to a higer version. Cu... Stefan From owner-arts@space.twc.de Fri Sep 3 15:03:54 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA21516 for arts-list; Fri, 3 Sep 1999 15:03:47 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id PAA21511; Fri, 3 Sep 1999 15:03:46 +0200 Message-ID: <19990903150345.55732@space.twc.de> Date: Fri, 3 Sep 1999 15:03:45 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems compiling 0.3.3 References: <19990902195145.22675@space.twc.de> <99090216455000.00617@nemesis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <99090216455000.00617@nemesis>; from ollidec@mailandnews.com on Thu, Sep 02, 1999 at 03:49:01PM -0500 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1912 Lines: 50 Hi! On Thu, Sep 02, 1999 at 03:49:01PM -0500, ollidec@mailandnews.com wrote: > I replaced the socketbits.h line with the ones you advise. > It compiled fine except for some enigmatic warnings, here they are: > > audioman_impl.cc: In method `AudioManager_impl::~AudioManager_impl()': > audioman_impl.cc:65: warning: implicit declaration of function `int close(...)' > audioman_impl.cc: In method `void AudioManager_impl::notifyIO(int)': > audioman_impl.cc:89: warning: implicit declaration of function `int write(...)' > audioman_impl.cc: In method `void AudioUplink_impl::notifyIO(int)': > audioman_impl.cc:304: warning: implicit declaration of function `int read(...)' > > autorouter.cpp: In method `void AutoRouter::thread_command_loop()': > autorouter.cpp:184: warning: implicit declaration of function `int usleep(...)' Okay, these are absolutely harmless - but I'll add the necessary includes in the next release to avoid this. > > Now I have this trouble I try to execute arts but nothing happened and then I > got this. Should I recompile mico?? > > [ernst@nemesis bin]$ artsbuilder > AR UP... > publishing module Gui_LABEL: > constructor > - module created > - not null > one GUIServer object freed => total 0 ArtsObjects alive > AR DOWN... > uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0, not-completed) > Aborted Do you have a libc5 system? Is it possible that you don't have threadsafe X11 libs (see documentation)? You could try to remove/comment out the line #define THREADED_ROUTING in src/ksbuild/autorouter.h, recompile the whole artsbuilder (make clean;make) and look if it fixes that problem. You also could try to get the threadsafe X11 libs as described in the docs. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Sep 3 19:28:46 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA22255 for arts-list; Fri, 3 Sep 1999 19:28:25 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from MailAndNews.com (mailandnews.com [206.156.199.130]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA22252 for ; Fri, 3 Sep 1999 19:28:21 +0200 Received: from nemesis [148.233.116.151] (ollidec@mailandnews.com); Fri, 3 Sep 1999 13:27:06 -0400 X-WM-Posted-At: MailAndNews.com; Fri, 3 Sep 99 13:27:06 -0400 From: Ernesto CEDILLO-ARIAS To: arts@space.twc.de Subject: Re: Problems compiling 0.3.3 Date: Fri, 3 Sep 1999 12:25:27 -0500 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <19990903150345.55732@space.twc.de> MIME-Version: 1.0 Message-Id: <99090312312200.00617@nemesis> Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2299 Lines: 62 Hello On Fri, 03 Sep 1999, you wrote: > Hi! > > On Thu, Sep 02, 1999 at 03:49:01PM -0500, ollidec@mailandnews.com wrote: > > I replaced the socketbits.h line with the ones you advise. > > It compiled fine except for some enigmatic warnings, here they are: > > > > audioman_impl.cc: In method `AudioManager_impl::~AudioManager_impl()': > > audioman_impl.cc:65: warning: implicit declaration of function `int close(...)' > > audioman_impl.cc: In method `void AudioManager_impl::notifyIO(int)': > > audioman_impl.cc:89: warning: implicit declaration of function `int write(...)' > > audioman_impl.cc: In method `void AudioUplink_impl::notifyIO(int)': > > audioman_impl.cc:304: warning: implicit declaration of function `int read(...)' > > > > autorouter.cpp: In method `void AutoRouter::thread_command_loop()': > > autorouter.cpp:184: warning: implicit declaration of function `int usleep(...)' > > Okay, these are absolutely harmless - but I'll add the necessary includes > in the next release to avoid this. > > > > > Now I have this trouble I try to execute arts but nothing happened and then I > > got this. Should I recompile mico?? > > > > [ernst@nemesis bin]$ artsbuilder > > AR UP... > > publishing module Gui_LABEL: > > constructor > > - module created > > - not null > > one GUIServer object freed => total 0 ArtsObjects alive > > AR DOWN... > > uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0, not-completed) > > Aborted > > Do you have a libc5 system? Is it possible that you don't have threadsafe > X11 libs (see documentation)? > > You could try to remove/comment out the line > > #define THREADED_ROUTING > > in src/ksbuild/autorouter.h, recompile the whole artsbuilder (make clean;make) > and look if it fixes that problem. > > You also could try to get the threadsafe X11 libs as described in the docs. > > Cu... Stefan > -- > -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany > KDE Developer, project infos at http://space.twc.de/~stefan/kde *- I have a libc6-glibc2.1 system. On the other hand I read something about this COMM failure in the mico FAQ. I believe it is a problem with my hostname/IP configuration. Something just too simple to be seen. And I can't figure it out. Thank you From owner-arts@space.twc.de Fri Sep 3 20:06:45 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA22458 for arts-list; Fri, 3 Sep 1999 20:06:44 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA22453; Fri, 3 Sep 1999 20:06:43 +0200 Message-ID: <19990903200643.51626@space.twc.de> Date: Fri, 3 Sep 1999 20:06:43 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems compiling 0.3.3 References: <19990903150345.55732@space.twc.de> <99090312312200.00617@nemesis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <99090312312200.00617@nemesis>; from Ernesto CEDILLO-ARIAS on Fri, Sep 03, 1999 at 12:25:27PM -0500 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2714 Lines: 83 Hi! On Fri, Sep 03, 1999 at 12:25:27PM -0500, Ernesto CEDILLO-ARIAS wrote: > > > [ernst@nemesis bin]$ artsbuilder > > > AR UP... > > > publishing module Gui_LABEL: > > > constructor > > > - module created > > > - not null > > > one GUIServer object freed => total 0 ArtsObjects alive > > > AR DOWN... > > > uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0, not-completed) > > > Aborted > > > > Do you have a libc5 system? Is it possible that you don't have threadsafe > > X11 libs (see documentation)? > > > > You could try to remove/comment out the line > > > > #define THREADED_ROUTING > > > > in src/ksbuild/autorouter.h, recompile the whole artsbuilder (make clean;make) > > and look if it fixes that problem. > > > > You also could try to get the threadsafe X11 libs as described in the docs. > > > > Cu... Stefan > > -- > > -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany > > KDE Developer, project infos at http://space.twc.de/~stefan/kde *- > > I have a libc6-glibc2.1 system. On the other hand I read something about > this COMM failure in the mico FAQ. I believe it is a problem with my hostname/IP > configuration. Something just too simple to be seen. And I can't figure it out. Well, checking if thats the problem should be pretty simple (however I don't assume it is). Use ping localhost if that works, aRts should work as well. But you can go even further testing: Start artsserver manually. Then use another Terminal window and type artsshell -i -s you should get something like: Scheduling cycle size: 128 samples (delay 2.90 ms with 44.1 kHz) Ring buffer size: 64 samples Cache size (for WAVs etc): 8192 KB Debugging information: disabled Active modules: 0 CPU usage: 0.00% 0 Memoryusage for cache (in KB) 0 SynthConnection object instances 0 SynthBuffer object instances 0 Total bytes in all SynthBuffers Further, type artsshell -f examples/example_stereobeep.arts -e in the directory you compiled aRts from (just important that it actually finds the file). It should play a stereo beep. If all that works, the aRts server and CORBA are allright, but artsbuilder is broken. In that case, try to recompile without threading anyway. Another question is which Qt version you are using? I got reports that Qt-1.44 may break things on a libc5 system, perhaps it also does on a libc6 sytem? In that case I'll need to install Qt-1.44 here, to do some debugging, I guess :( Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Sep 6 19:17:40 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA30184 for arts-list; Mon, 6 Sep 1999 19:16:34 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id TAA30179; Mon, 6 Sep 1999 19:16:33 +0200 Message-ID: <19990906191633.49490@space.twc.de> Date: Mon, 6 Sep 1999 19:16:33 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: aRts-0.3.3 on RedHat-6.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2713 Lines: 116 Hi! As some people reported me that they are experiencing problems with RedHat-6.0 and aRts - mainly that Artsbuilder isn't starting - I tried to reproduce this here. No chance: everything went fine, no unexpected problems. However, I have written down what I did, as there are some problems you will run into when compiling under RH6, though they are all documented (either with mails on the list or in the README). Before installation: Installation of a fresh RedHat-6.0, with KDE. Installation of the soundcard in RedHat with sndconfig (as root). Test of the soundcard with x11amp (or any other program). ==> As user stefan@rh6:~/src> tar -zxf mico-2.2.7.tar.gz stefan@rh6:~/src> cd mico stefan@rh6:~/src/mico> ./configure --disable-mini-stl stefan@rh6:~/src/mico> make ==> As root root@rh6:~/src/mico# make install ==> As user stefan@rh6:~/src/arts-0.3.3> tar -zxf arts-0.3.3.tar.gz stefan@rh6:~/src/arts-0.3.3> cd arts-0.3.3 stefan@rh6:~/src/arts-0.3.3> ./configure == occuring problem: checking for QT... configure: error: QT-1.3 (headers and libraries) not found. P lease check your installation! ==> As root start gnorpm install the package qt-devel from the RedHat6.0 CD. ==> As user stefan@rh6:~/src/arts-0.3.3> make == occuring problem: /usr/local/bin/idl --query-server-for-narrow synth.idl /usr/local/bin/idl: error in loading shared libraries: libmico2.2.7.so: cannot open shared object file: No such file or directory ==> As root add /usr/local/lib to /etc/ld.so.conf root@rh6:~/src/arts-0.3.3# ldconfig ==> As user stefan@rh6:~/src/arts-0.3.3> make == occuring problem: wav.cc:36: parse error before `}' ==> As root remove one of the two closing brackets that are used when __cplusplus is defined. That is three lines starting from 59 in file /usr/include/aupvlist.h #ifdef __cplusplus } #endif (or upgrade your libaudiofile to something above 0.1.6) ==> As user stefan@rh6:~/src/arts-0.3.3> make == occuring problem: audioman_impl.cc:23: socketbits.h: Datei oder Verzeichnis nicht gefunden == fix: replace the line #include by #include #include #include ==> As user stefan@rh6:~/src/arts-0.3.3> make ==> As root root@rh6:~/src/arts-0.3.3# make install root@rh6:~/src/arts-0.3.3# cd /usr/bin root@rh6:/usr/bin# chown root artsserver.bin root@rh6:/usr/bin# chmod u+s artsserver.bin ==> As user stefan@rh6:~/src/arts-0.3.3> artsbuilder [... voila - everything works fine ...] Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Sep 11 07:32:42 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id HAA11704 for arts-list; Sat, 11 Sep 1999 07:31:59 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from limdns2.unilim.fr (limdns2.unilim.fr [164.81.1.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id HAA11701 for ; Sat, 11 Sep 1999 07:31:57 +0200 Received: from alpha1.unilim.fr (alpha1.unilim.fr [164.81.1.12]) by limdns2.unilim.fr (8.8.8/jtpda-5.2.9.2) with ESMTP id FAA20517 for ; Sat, 11 Sep 1999 05:32:55 GMT Received: from localhost.localdomain (ppp11.unilim.fr [164.81.1.241]) by alpha1.unilim.fr (8.8.8/jtpda-5.3) with SMTP id HAA13877 for ; Sat, 11 Sep 1999 07:32:55 +0200 (MET DST) From: Ludovic Grossard To: arts@space.twc.de Subject: problem compiling : need help !!! Date: Sat, 11 Sep 1999 07:27:00 +0200 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99091107330500.00418@localhost.localdomain> Content-Transfer-Encoding: 8bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1559 Lines: 36 Hi I am the KDE Team french translator of aRts and I need to compile aRts (better if you want to translate it :o) So I Tried to compile aRts, but the following error occurs : [root@localhost arts-0.3.3]# make make all-recursive make[1]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3' Making all in src make[2]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src' Making all in common make[3]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src/common' /usr/local/bin/idl --query-server-for-narrow midibus.idl /usr/local/bin/idl: error in loading shared libraries libmico2.2.7.so: cannot open shared object file: No such file or directory make[3]: *** [midibus.h] Error 127 make[3]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src/common' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3' make: *** [all-recursive-am] Error 2 I installed mico 2.2.7 (compiled with --disable-mini-stl as explained in the doc), and it has been detected without problem while the configure process. Can anybody help me ? Thanks in advance... -- -------------------------------------------- Ludovic Grossard grossard@unilim.fr, grossard@netcourrier.com The software said it requires Win95 or better, so I installed Linux. -------------------------------------------- From owner-arts@space.twc.de Sat Sep 11 11:22:26 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id LAA12004 for arts-list; Sat, 11 Sep 1999 11:22:23 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id LAA11999; Sat, 11 Sep 1999 11:22:22 +0200 Message-ID: <19990911112222.27167@space.twc.de> Date: Sat, 11 Sep 1999 11:22:22 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: problem compiling : need help !!! References: <99091107330500.00418@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <99091107330500.00418@localhost.localdomain>; from Ludovic Grossard on Sat, Sep 11, 1999 at 07:27:00AM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2169 Lines: 52 Hi! On Sat, Sep 11, 1999 at 07:27:00AM +0200, Ludovic Grossard wrote: > I am the KDE Team french translator of aRts and I need to compile aRts (better > if you want to translate it :o) So I Tried to compile aRts, but the following > error occurs : Translating is a good idea - I am not sure if I did set up anything right with makefiles and translation etc. - tell me if you run ito problems with that. > [root@localhost arts-0.3.3]# make > make all-recursive > make[1]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3' > Making all in src > make[2]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src' > Making all in common > make[3]: Entering directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src/common' > /usr/local/bin/idl --query-server-for-narrow midibus.idl > /usr/local/bin/idl: error in loading shared libraries > libmico2.2.7.so: cannot open shared object file: No such file or directory > make[3]: *** [midibus.h] Error 127 > make[3]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src/common' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/grossard/documents/traduction/ksynth/arts-0.3.3' > make: *** [all-recursive-am] Error 2 > > I installed mico 2.2.7 (compiled with --disable-mini-stl as explained in the > doc), and it has been detected without problem while the configure process. > > Can anybody help me ? Thanks in advance... You could have found that in the mailinglist archive: == occuring problem: /usr/local/bin/idl --query-server-for-narrow synth.idl /usr/local/bin/idl: error in loading shared libraries: libmico2.2.7.so: cannot +open shared object file: No such file or directory ==> As root add /usr/local/lib to /etc/ld.so.conf root@rh6:~/src/arts-0.3.3# ldconfig Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Sep 11 18:25:44 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA12521 for arts-list; Sat, 11 Sep 1999 18:25:31 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id SAA12518 for ; Sat, 11 Sep 1999 18:25:28 +0200 Received: (qmail 9665 invoked by uid 0); 11 Sep 1999 16:26:32 -0000 Received: from host-62.96.52.215.inetservice.de (HELO gate.way) (62.96.52.215) by mail1.gmx.net with SMTP; 11 Sep 1999 16:26:32 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id SAA03694 for arts@space.twc.de; Sat, 11 Sep 1999 18:34:07 +0200 Date: Sat, 11 Sep 1999 18:34:07 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Midi-Channel splitting & Co. Message-ID: <19990911183256.A3604@gate> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IrhDeMKUP4DT/M7F" X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 9028 Lines: 318 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Hi ! I'm trying to learn playing keyboard. To do this i've borrowed a old Roland Poly-800II analog digital syntiziser from a friend. The problem on this is, it's realy old. The syntiziser "crashs" (detune,noise) the tone very often. But it has a more or less stable midi signal, so i'm using my PC for creating the tone. At first, i could only do this on windows (using a Midi Input<->Output mapper programm). I've tried all programms on linux i could find - But the only program that worked for me, is aRTs. I'm very happy with aRTs, it generates a real good synth tone ! I've used a simple standard setup for this until 0.3.3 - Load artsserver (0.3.0), upload an instrument and than execute the main. On an other termial start midisend. But now with aRTs 0.3.3 it realy gets great - I can use more than one instrument at once, and i can map than on different midichannels. The only problem is, that the midiinput is only on channel 0. It would be nice, if i could e.g. splitt my keyboard and map the upper and the lower keys on an other instrument. Attached is a patched midisend.cc, wich allows to do this. It reads the config from the file midisend.map from the current dir. It's a realy dirty 1 hour hack. So it's perhaps very instable. You can do the following with it: - Channelchange: If this pitch comes in, than change the channel to X. - Pitchchange: If this pitch comes in, than add/substract X to/from it. With this, you can not only simple split your keyboard, you can make it also like a "normal keyboard". E.g. you can put a drum on a key. It should someday also can do this: - Dynamic changerule changes. If a "special pitch" comes in, switch the rules. - Use it to make a Apregiator I don't know if midisend is the right place to do this. Perhaps it should be installed somewhere in the midibus. Where is this to do best ? One thing i'm realy missing is the possiblty to save the configuration of an executing artsserver. This could be usefull, if you not want to re-add all your XX-instrumments for the different channels everytime. cu, Emmy P.S.: To get aRTs 0.3.3 compiled on my SuSe6.1 i had to patch a file audio??? (forgot exact name) in /usr/include (#ifdef-block on the end of the file was wrong). Is this a known issue with SuSE6.1 ? -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="midisend.map" # Small example midimap # This file is for a 49 key keyboard # #MUST be format Rxxx;xxx;xxx;xxx otherwise the programm will crash #Orig Channel,From Pitch,To Pitch, Dest Channel #R 0; 1; 59; 1; # #MUST be format Pxxx;xxx;xxx;xxx otherwise the programm will crash #Orig Channel,From Pitch,To Pitch, Pitch Diff #P 0; 1; 59;-24; # # Sample: The first part of the keyboard one octave down #P 0; 1; 59;-12; # # Sample: Split the keyboard -> firstpart is on channel 2, second on channel 1 # Both are on the same octave R 0; 1; 59; 1; P 0; 1; 59; 24; # --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="midisend.cc" /* ** Cleaner version of midisend, by David G. Slomin. ** Released to the Public Domain, 1/25/99. */ #include #include #include #include #include #include "midibus.h" #include #include extern "C" { #include "midimsg.h" } class CMidiMap { public: void ReadMap(const char* pszFileName); void MapMsg(Byte* msg); private: void ParseLine(char* pszLine); private: struct ChannelMaps { int nChannel; struct ChannelRemap { int nPitch; int nChannel; }; struct PitchRemap { int nPitch; int nToPitch; }; typedef map ChannelRemapMap; ChannelRemapMap channelRemaps; typedef map PitchRemapMap; PitchRemapMap pitchRemaps; }; typedef map ChannelMapsMap; ChannelMapsMap channelMaps; }; void CMidiMap::ReadMap(const char* pszFileName) { FILE *file = fopen(pszFileName,"r"); if( !file ) return; char cBuffer[1024+1]; char* pszLine; while( (pszLine = fgets(cBuffer,1024,file)) ) { ParseLine(pszLine); } fclose(file); } void CMidiMap::ParseLine(char* pszLine) { // Skip comments if(*pszLine == '#') return; // Range Map if(*pszLine == 'R') { // MUST be format Rxxx;xxx;xxx;xxx otherwise the programm will crash // Orig Channel,From Pitch,To Pitch, Dest Channel pszLine++; pszLine[3] = 0; int nOrigChannel = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nStart = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nEnd = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nChannel = atol(pszLine); channelMaps[nOrigChannel].nChannel = nOrigChannel; for( int i = nStart; i <= nEnd; i++ ) { channelMaps[nOrigChannel].channelRemaps[i].nPitch = i; channelMaps[nOrigChannel].channelRemaps[i].nChannel = nChannel; } } if(*pszLine == 'P') { // MUST be format Pxxx;xxx;xxx;xxx otherwise the programm will crash // Orig Channel,From Pitch,To Pitch, Pitch Diff pszLine++; pszLine[3] = 0; int nOrigChannel = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nStart = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nEnd = atol(pszLine); pszLine += 4; pszLine[3] = 0; int nPitchDiff = atol(pszLine); channelMaps[nOrigChannel].nChannel = nPitchDiff; for( int i = nStart; i <= nEnd; i++ ) { channelMaps[nOrigChannel].pitchRemaps[i].nPitch = i; channelMaps[nOrigChannel].pitchRemaps[i].nToPitch = i + nPitchDiff; } } } void CMidiMap::MapMsg(Byte* msg) { int nChannel = midimsgGetChannel(msg); int nPitch = midimsgGetPitch(msg); if( channelMaps.find(nChannel) != channelMaps.end() ) { if( channelMaps[nChannel].channelRemaps.find(nPitch) != channelMaps[nChannel].channelRemaps.end() ) { midimsgSetChannel(msg,channelMaps[nChannel].channelRemaps[nPitch].nChannel); } if( channelMaps[nChannel].pitchRemaps.find(nPitch) != channelMaps[nChannel].pitchRemaps.end() ) { midimsgSetPitch(msg,channelMaps[nChannel].pitchRemaps[nPitch].nToPitch); } } } #ifdef COMMON_BINARY int midisend_main(int argc, char *argv[]) #else int main(int argc, char *argv[]) #endif { /* ** CORBA initialization. */ CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb"); CORBA::BOA_var boa = orb->BOA_init(argc, argv, "mico-local-boa"); CORBA::Object_var obj = orb->bind("IDL:MidiChannel:1.0", "inet:localhost:8888"); if (CORBA::is_nil(obj)) { fprintf(stderr, "%s trouble: No midichannel CORBA object found; please start " "artsserver.\n",argv[0]); exit(EXIT_FAILURE); } MidiChannel_var midich = MidiChannel::_narrow(obj); /* ** MIDI input initialization. */ int input_fd = -1, test = 0; switch (argc) { case 1: input_fd = open("/dev/midi", O_RDONLY); break; case 2: input_fd = ((strcmp(argv[1], "-") == 0) ? 0 : open(argv[1], O_RDONLY)); if(strcmp(argv[1],"--test") == 0) test = 1; if(strcmp(argv[1],"--longtest") == 0) test = 2; break; default: fprintf(stderr, "Usage: %s [input-device-or-fifo]\n", argv[0]); fprintf(stderr, "where the input device is /dev/midi if " "unspecified\n"); fprintf(stderr, "or stdin if you specify a dash\n"); fprintf(stderr, "or test if you specify --test\n"); exit(EXIT_FAILURE); break; } if(test) { unsigned long i,max=5000; if(test==2) max = 20000; for(i=0;inoteOn(0, 60+(i%12), 100); midich->noteOff(0, 60+(i%12)); } exit(0); } if(input_fd == -1) { fprintf(stderr,"%s trouble: can't open input device!\n",argv[0]); exit(EXIT_FAILURE); } /* ** Main loop. */ CMidiMap Map; Map.ReadMap("midisend.map"); unsigned char msg[3]; while (1) { midimsgRead(input_fd, msg); switch (midimsgGetMessageType(msg)) { case MIDIMSG_NOTE_OFF: Map.MapMsg(msg); midich->noteOff(midimsgGetChannel(msg), midimsgGetPitch(msg)); printf("NoteOff: %ld; %ld\n", midimsgGetChannel(msg),midimsgGetPitch(msg)); break; case MIDIMSG_NOTE_ON: Map.MapMsg(msg); midich->noteOn(midimsgGetChannel(msg), midimsgGetPitch(msg), midimsgGetVelocity(msg)); printf("NoteOn: %ld; %ld; %ld\n", midimsgGetChannel(msg),midimsgGetPitch(msg),midimsgGetVelocity(msg)); break; } } } --IrhDeMKUP4DT/M7F-- From owner-arts@space.twc.de Sun Sep 12 22:28:18 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA17149 for arts-list; Sun, 12 Sep 1999 22:28:05 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id WAA17144; Sun, 12 Sep 1999 22:28:03 +0200 Message-ID: <19990912222803.49003@space.twc.de> Date: Sun, 12 Sep 1999 22:28:03 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Midi-Channel splitting & Co. References: <19990911183256.A3604@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990911183256.A3604@gate>; from Emmeran Seehuber on Sat, Sep 11, 1999 at 06:34:07PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 3333 Lines: 75 Hi! On Sat, Sep 11, 1999 at 06:34:07PM +0200, Emmeran Seehuber wrote: > [...] > > I'm very happy with aRTs, it generates a real good synth tone ! Thats good to hear ;) > Attached is a patched midisend.cc, wich allows to do this. > It reads the config from the file midisend.map from the current dir. > It's a realy dirty 1 hour hack. So it's perhaps very instable. > > You can do the following with it: > - Channelchange: If this pitch comes in, than change the channel to X. > - Pitchchange: If this pitch comes in, than add/substract X to/from it. > > With this, you can not only simple split your keyboard, you can make > it also like a "normal keyboard". E.g. you can put a drum on a key. That thing is really useful. I played quite a while with it today, and it is just nice to have more than one voice. About drum keys: the next aRts release will provide you with the ability to create drum maps, so you can map every key to a different wave and similar things. > It should someday also can do this: > - Dynamic changerule changes. If a "special pitch" comes in, switch the rules. > - Use it to make a Apregiator > > I don't know if midisend is the right place to do this. Perhaps it should > be installed somewhere in the midibus. Where is this to do best ? The right thing to do in the long run would be to extend the aRts flow system towards handling midi flow (it currently only handles audio_data and string_data), so you could do little modules, which split signal flow, filter events, change them (like arpegiator), or do things like styles in a keyboard, or whatever. However, that's quite a bit tricky work to do. If you want to work on that, you can go ahead, but you'll need to get deep down into the internals... I will do that some day anyway - but there is no planned point in time, when. On the other hand, an extended midisend could be included in aRts, as long as midiflow isn't handled modular, and moved into modules later. If you could do the following: - make midisend option parsing with getopts (see artsshell for reference - accept a -M option (and the other test options as well) - make the fileformat more robust - make it reasonable crashproof (you write that it may crash on bad input files) - document it properly (text will do, I'll include it in the SGML then) then I could include your extensions in the next aRts release, which is scheduled for something like Sunday next week (don't trust that though, it's done when it's done). > One thing i'm realy missing is the possiblty to save the configuration of > an executing artsserver. This could be usefull, if you not want to re-add > all your XX-instrumments for the different channels everytime. Yes, I want to write a session management thing for the next aRts release, which can be used to restore all settings, like mixer parameters, used/mapped instruments, instrument parameters, etc. > P.S.: To get aRTs 0.3.3 compiled on my SuSe6.1 i had to patch a file audio??? > (forgot exact name) in /usr/include (#ifdef-block on the end of the file > was wrong). Is this a known issue with SuSE6.1 ? Yes, it is (it is a libaudiofile-0.1.6 problem). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Sep 13 10:09:17 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id KAA18285 for arts-list; Mon, 13 Sep 1999 10:08:24 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id KAA18282 for ; Mon, 13 Sep 1999 10:08:17 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id JAA00693 for ; Mon, 13 Sep 1999 09:09:53 +0200 (MET DST) Date: Mon, 13 Sep 1999 09:09:49 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Menu too long In-Reply-To: <19990912222803.49003@space.twc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 362 Lines: 13 Hi, I was playing around with the latest arts yesterday. I noticed that the menu that contain the synth modules has gotten too long, i.e. I can't get to synth-wave* because the lower part of the menu is not displayed on the 800x600 laptop screen. Regards, Reiner -- Dr.-Ing. Reiner Klenk Hahn-Meitner-Institut Berlin Tel: +49 30 8062 2625 E-mail: klenk@hmi.de From owner-arts@space.twc.de Mon Sep 13 12:36:27 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA18553 for arts-list; Mon, 13 Sep 1999 12:35:03 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id MAA18548; Mon, 13 Sep 1999 12:35:02 +0200 Message-ID: <19990913123502.64357@space.twc.de> Date: Mon, 13 Sep 1999 12:35:02 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Menu too long References: <19990912222803.49003@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Reiner Klenk on Mon, Sep 13, 1999 at 09:09:49AM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 623 Lines: 15 Hi! On Mon, Sep 13, 1999 at 09:09:49AM +0200, Reiner Klenk wrote: > Hi, I was playing around with the latest arts yesterday. I noticed that > the menu that contain the synth modules has gotten too long, i.e. I can't > get to synth-wave* because the lower part of the menu is not displayed on > the 800x600 laptop screen. The next release will have a more sophisticated menu structure (more levels), which means that the menus won't get that large any more. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Sep 13 12:51:18 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA18632 for arts-list; Mon, 13 Sep 1999 12:51:17 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id MAA18626; Mon, 13 Sep 1999 12:51:16 +0200 Message-ID: <19990913125115.31644@space.twc.de> Date: Mon, 13 Sep 1999 12:51:15 +0200 From: Stefan Westerfeld To: czxpenguin@my-deja.com Cc: arts@space.twc.de Subject: Re: artsenv & static aRts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 655 Lines: 22 Hi! > I downloaded the STATIC arts package and uncompressed it into the > appropriate directory. However, whenever I try to run artsserver > (after running artssenv), I get this error: > > --- initializing Arts Synthesizer object --- > ./artsserver: artsserver.bin: command not found > Terminated abnormally (1902) > > Could someone please help me? I really want to use ARTS! thanks, You need to source artsenv with . /usr/local/arts/bin/artsenv not just run it. (The dot is important). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Sep 13 22:06:57 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA19752 for arts-list; Mon, 13 Sep 1999 22:06:39 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id WAA19749 for ; Mon, 13 Sep 1999 22:06:36 +0200 Received: (qmail 6400 invoked by uid 0); 13 Sep 1999 19:48:58 -0000 Received: from host-62.96.51.18.inetservice.de (HELO gate.way) (62.96.51.18) by mail1.gmx.net with SMTP; 13 Sep 1999 19:48:58 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id VAA24417 for arts@space.twc.de; Mon, 13 Sep 1999 21:55:56 +0200 Date: Mon, 13 Sep 1999 21:55:56 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Midi-Channel splitting & Co. Message-ID: <19990913215556.A23343@gate> References: <19990911183256.A3604@gate> <19990912222803.49003@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <19990912222803.49003@space.twc.de> Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 6262 Lines: 131 On Sun, Sep 12, 1999 at 10:28:03PM +0200, Stefan Westerfeld wrote: > [...] > About drum keys: the next aRts release will provide you with the ability > to create drum maps, so you can map every key to a different wave and > similar things. > Does this means this: You have a special drum instrument, wich just maps each pitch to an other drum-wave ? > > It should someday also can do this: > > - Dynamic changerule changes. If a "special pitch" comes in, switch the rules. > > - Use it to make a Apregiator > > > > I don't know if midisend is the right place to do this. Perhaps it should > > be installed somewhere in the midibus. Where is this to do best ? > > The right thing to do in the long run would be to extend the aRts flow > system towards handling midi flow (it currently only handles audio_data > and string_data), so you could do little modules, which split signal flow, > filter events, change them (like arpegiator), or do things like styles > in a keyboard, or whatever. > > However, that's quite a bit tricky work to do. If you want to work on that, > you can go ahead, but you'll need to get deep down into the internals... I > will do that some day anyway - but there is no planned point in time, when. > Ok, i'll try my luck. I already know how to programm COM, but i've never did CORBA before. So it gets time, that i learn this thing. :-) I had quick look at the arts.idl. At the first look it seems not to be so complicated. (ArtsObject looks a little like COM-IUnknown :-)) - But be prepared for some questions ... :-) --- I think, the midiflow should directly pass throu the midimessage. Than you would have the following modules to do something with it: - MidiIn: There the Midi-Input comes in. Midisend sends the messages direct to MidiIn IN: - OUT: Midimessage - MidiMapper: Maps the midiinput to the arts-instrument. (Like MAPPER-Modul). Should be based on the MAPPER-Modul (or should be an changed MAPPER-Modul) IN: Midimessage OUT: - - MidiSplitter: Splits a midimessage in it's parts. This parts are then integers/reals wich (as far as i know) also is equal to "audio_data". With this, you can apply all normal audio-modules on it. May make sense with velocity and pitchbend. It could also be usefull, if aRTs gets conditional modules. (e.g. If pitchbend reaches a specified level, then switch to other instrument) IN: Midimessage OUT: Channel, Pitch, Velocity, Pitchbend, ... - MidiJoiner: The opposite to MidiSplitter. After you've changed some componets, you get back a midimessage. IN: Channel, Pitch, Velocity, Pitchbend, ... OUT: Midimessage - MidiChannelPitchMapper: Changes the channel of the message according to the configured channel&pitch->channel map. This requiers a configuration dialog (or widget). Should this dialog be displayed at executetime of the server (like the MAPPER-Modul), or should it be a extended propertyeditor of the modul? IN: Midimessages OUT: Midimessage GUI: Widget to edit the map - MidiPitchPitchMapper: Changes the pitch of the message according to the configured channel&pitch->pitch map. Same thing for GUI as by he MidiChannelPitchMapper. IN: Midimessages OUT: Midimessage GUI: Widget to edit the map - MidiArpegiator: Just what the name say. The arpregiator starts playing when a noteon comes in. It stops playing when a noteoff commes in. Between this time all xxx secs a timer(or whatever) must activate this modul so that it can send an other note according to the sequence. How must such a modul be implement? Are there examples for such a timing? IN: Midimessage OUT: Midimessage GUI: Widget to edit the arpegiator. One instance holds only one sequence per channel. If you want to have more then one arpegiator-sequence you must split your keyboard or use conditunal modules for this. - Midi"Begleitautomatik" (What's that in english?): When a message with a note comes in, this modul generates additional notes. This is usefull to make acords. E.g. if note C2 comes in, it outputs C2,E2,G1. IN: Midimessage OUT: Sequence of midimessages. Would it work to give out the messages in sequence ? - Boolean-Modules: Implements boolean operations. IN: Operand1, Operand2, Kind of Operation(Equal,Lower,Higher,And,Or,...) Should each operation have an own modul ? Must this modules be implemented different for each type? (as far as i see from the idl it must at the moment; One port can only have one type) OUT: Boolean-Result (true,false) - Compare-Modul: If IN is true, it will pass throu the first input, otherwiese the second. IN: Boolean-Switch,Input1,Input2. Same question on types as by the boolean-modules OUT: Result What do you think about this ? Is the design idea ok? Are the names ok? Are modules missing ? > On the other hand, an extended midisend could be included in aRts, as long > as midiflow isn't handled modular, and moved into modules later. If you > could do the following: > > - make midisend option parsing with getopts (see artsshell for reference > - accept a -M option (and the other test options as well) > - make the fileformat more robust > - make it reasonable crashproof (you write that it may crash on bad input > files) > - document it properly (text will do, I'll include it in the SGML then) > > then I could include your extensions in the next aRts release, which is > scheduled for something like Sunday next week (don't trust that though, > it's done when it's done). > Ok, i'll do it. -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Tue Sep 14 20:35:11 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA21535 for arts-list; Tue, 14 Sep 1999 20:34:59 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by space.twc.de (8.8.7/8.8.7) with SMTP id UAA21532 for ; Tue, 14 Sep 1999 20:34:55 +0200 Received: from Unknown/Local ([?.?.?.?]) by my-deja.com; Tue Sep 14 11:35:24 1999 To: arts@space.twc.de Date: Tue, 14 Sep 1999 11:35:24 -0700 From: "Steven X. Downer" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service Subject: Unable to Start Midisend X-Sender-Ip: 166.62.133.169 Organization: My Deja Email (http://www.my-deja.com:80) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 276 Lines: 10 Well, I got the artsserver and artsbuilder started but when I try to run midisend I get this message: midisend trouble: can't open input device! Can someone please help me? thanks --== Sent via Deja.com http://www.deja.com/ ==-- Share what you know. Learn what you don't. From owner-arts@space.twc.de Wed Sep 15 15:17:22 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA23192 for arts-list; Wed, 15 Sep 1999 15:16:51 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA23189 for ; Wed, 15 Sep 1999 15:16:49 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id PAA15602 for ; Wed, 15 Sep 1999 15:18:02 +0200 (MET DST) Date: Wed, 15 Sep 1999 15:18:01 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: Unable to Start Midisend In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 291 Lines: 11 On Tue, 14 Sep 1999, Steven X. Downer wrote: > Well, I got the artsserver and artsbuilder started but when I try to run midisend I get this message: > > midisend trouble: can't open input device! > what is the output of cat /dev/sndstat ? what is the output of ls -l /dev/midi ? Reiner From owner-arts@space.twc.de Wed Sep 15 18:49:07 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA23552 for arts-list; Wed, 15 Sep 1999 18:49:04 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id SAA23548 for ; Wed, 15 Sep 1999 18:49:02 +0200 Received: (qmail 22056 invoked by uid 0); 15 Sep 1999 16:50:15 -0000 Received: from host-62.96.52.196.inetservice.de (HELO gate.way) (62.96.52.196) by mail1.gmx.net with SMTP; 15 Sep 1999 16:50:15 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id SAA00848 for arts@space.twc.de; Wed, 15 Sep 1999 18:58:08 +0200 Date: Wed, 15 Sep 1999 18:58:08 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Unable to Start Midisend Message-ID: <19990915185808.A830@gate> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 796 Lines: 21 On Tue, Sep 14, 1999 at 11:35:24AM -0700, Steven X. Downer wrote: > Well, I got the artsserver and artsbuilder started but when I try to run midisend I get this message: > > midisend trouble: can't open input device! midisend trys to open /dev/midi for midiinput by default. This perhaps does not work for your system. On my system (SuSE6.1 Linux) i must start midisend and specify the mididevice explicit. It is /dev/midi00 for my case. Just try this: $ midisend /dev/midi00 and if this does not work, check if you have compiled midi-support in your kernel, and if there exists /dev/*midi*-files. -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Wed Sep 15 20:04:57 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA23705 for arts-list; Wed, 15 Sep 1999 20:04:54 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id UAA23702 for ; Wed, 15 Sep 1999 20:04:52 +0200 Received: (qmail 5088 invoked by uid 0); 15 Sep 1999 18:06:07 -0000 Received: from host-62.96.49.71.inetservice.de (HELO gate.way) (62.96.49.71) by mail2.gmx.net with SMTP; 15 Sep 1999 18:06:07 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id UAA04007 for arts@space.twc.de; Wed, 15 Sep 1999 20:14:09 +0200 Date: Wed, 15 Sep 1999 20:14:09 +0200 From: Emmeran Seehuber To: Arts Mailing List Subject: What is the license of midisend ? Message-ID: <19990915201409.A4003@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 403 Lines: 14 midisend.cc does only say it is released to the public domain by David G. Slomin. But is it realy GPL ? I want to have my changes coverd by GPL. Can i just safe add the GPL-Header to the source ? cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Thu Sep 16 18:41:32 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id SAA25744 for arts-list; Thu, 16 Sep 1999 18:40:41 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id SAA25739; Thu, 16 Sep 1999 18:40:40 +0200 Message-ID: <19990916184040.20417@space.twc.de> Date: Thu, 16 Sep 1999 18:40:40 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: What is the license of midisend ? References: <19990915201409.A4003@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990915201409.A4003@gate>; from Emmeran Seehuber on Wed, Sep 15, 1999 at 08:14:09PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1175 Lines: 30 Hi! On Wed, Sep 15, 1999 at 08:14:09PM +0200, Emmeran Seehuber wrote: > midisend.cc does only say it is released to > the public domain by David G. Slomin. But is > it realy GPL ? Public domain means, that there are no restrictions of what you can do with it. For instance, you may just take midisend, make some minor changes (fix a bug), and sell the result, without providing the source any longer. GPL would disallow that, making it free software in a GNU sense of the word, of course for instance prohibiting the integration of midisend code in a commercial sequencer like AudioLogic (which would basically work, even if AudioLogic runs on windows, since there is CORBA, but thats another thing). > I want to have my changes coverd by GPL. > > Can i just safe add the GPL-Header to the source ? Yes, you can (the public domain license permits you doing everything with the code), and I have no objections against including a GPLd midisend in further versions of aRts, instead of a public domain one. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Thu Sep 16 19:31:07 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA25847 for arts-list; Thu, 16 Sep 1999 19:31:01 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id TAA25842; Thu, 16 Sep 1999 19:31:00 +0200 Message-ID: <19990916193100.20491@space.twc.de> Date: Thu, 16 Sep 1999 19:31:00 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Midi-Channel splitting & Co. References: <19990911183256.A3604@gate> <19990912222803.49003@space.twc.de> <19990913215556.A23343@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990913215556.A23343@gate>; from Emmeran Seehuber on Mon, Sep 13, 1999 at 09:55:56PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 12346 Lines: 287 Hi! On Mon, Sep 13, 1999 at 09:55:56PM +0200, Emmeran Seehuber wrote: > On Sun, Sep 12, 1999 at 10:28:03PM +0200, Stefan Westerfeld wrote: > > [...] > > About drum keys: the next aRts release will provide you with the ability > > to create drum maps, so you can map every key to a different wave and > > similar things. > > > Does this means this: You have a special drum instrument, wich just maps each pitch > to an other drum-wave ? I have a special midi router, which can route mapped instruments. The standard scheme for a router is: each time a key is pressed, a structure is created, which gets frequency, velocity and a "pressed" flag. That structure may for instance just play a sample (with Synth_PLAY_WAV), or synthesize something, or ... Mapped routers allow to pass additional arguments to the structure, depending what the pitch of the note was, so that you could use one sample for one range of keys (or a single key), and another for the next range of keys. Thus, you can (if I do wave resampling, for akai that works) for instance have a piano, that is playing & resampling different samples on different octaves, or for instance have a drum map. > > > It should someday also can do this: > > > - Dynamic changerule changes. If a "special pitch" comes in, switch the rules. > > > - Use it to make a Apregiator > > > > > > I don't know if midisend is the right place to do this. Perhaps it should > > > be installed somewhere in the midibus. Where is this to do best ? > > > > The right thing to do in the long run would be to extend the aRts flow > > system towards handling midi flow (it currently only handles audio_data > > and string_data), so you could do little modules, which split signal flow, > > filter events, change them (like arpegiator), or do things like styles > > in a keyboard, or whatever. > > > > However, that's quite a bit tricky work to do. If you want to work on that, > > you can go ahead, but you'll need to get deep down into the internals... I > > will do that some day anyway - but there is no planned point in time, when. > > > Ok, i'll try my luck. I already know how to programm COM, but i've never did > CORBA before. So it gets time, that i learn this thing. :-) > > I had quick look at the arts.idl. At the first look it seems not to > be so complicated. (ArtsObject looks a little like COM-IUnknown :-)) > - But be prepared for some questions ... :-) Sure. There might be two useful ways to go: either, you derive of ArtsServer, and implement a whole new flow server for midi flow, that will run besides the synthesis server. This will allow you to do an independant concept of base classes, communication and scheduling for midi events. Of course you get problems then when writing modules that should have both, signal flow, and process midi events (such as a thing that converts a midi controller into a signal). The other way is extending the internal communication model which is used during scheduling to handle midi event based communication as well. That is mainly changing SynthModule and Synthesizer_impl::Run (but not only). More about this below. > I think, the midiflow should directly pass throu the midimessage. Than you would > have the following modules to do something with it: > - MidiIn: There the Midi-Input comes in. Midisend sends the messages direct to > MidiIn > IN: - > OUT: Midimessage Yes. > - MidiMapper: Maps the midiinput to the arts-instrument. (Like MAPPER-Modul). > Should be based on the MAPPER-Modul (or should be an changed > MAPPER-Modul) > IN: Midimessage > OUT: - Well, there are some INs missing for the mapper functionality (like what structure to map to, etc). > - MidiSplitter: Splits a midimessage in it's parts. This parts are then > integers/reals wich (as far as i know) also is equal to > "audio_data". With this, you can apply all normal audio-modules > on it. May make sense with velocity and pitchbend. It could > also be usefull, if aRTs gets conditional modules. (e.g. If > pitchbend reaches a specified level, then switch to other > instrument) > IN: Midimessage > OUT: Channel, Pitch, Velocity, Pitchbend, ... Yes. > - MidiJoiner: The opposite to MidiSplitter. After you've changed some componets, > you get back a midimessage. > IN: Channel, Pitch, Velocity, Pitchbend, ... > OUT: Midimessage Yes. > - MidiChannelPitchMapper: Changes the channel of the message according to the > configured channel&pitch->channel map. This requiers a > configuration dialog (or widget). Should this dialog > be displayed at executetime of the server (like the > MAPPER-Modul), or should it be a extended propertyeditor > of the modul? > IN: Midimessages > OUT: Midimessage > GUI: Widget to edit the map I think a nice (but complex) solution would be: Extend property passing to pass not only audio_data and string_data types, but also to pass composed types like midi events, samples, such maps you talk of, envelopes (think of fasttrackers panning or volume envelopes) etc. All that needs to be done for aRts sooner or later anyway. A less complex solution might look like current midi mapping code: 1. You have a synthesis module, which performs one mapping operation and has that specified as parameters. So Midi_CHANNEL_PITCH_MAPPER might be INs: midimessage, channel, pitch, newchannel OUT: midimessage 2. You have a gui module, which creates a battery of Midi_CHANNEL_PITCH_MAPPERs, one for each mapping operation. The second solution may be easier to implement for one or two more affected modules, while the first solution could be the generic solution for every module that needs more complex data structures as parameters. > - MidiPitchPitchMapper: Changes the pitch of the message according to the > configured channel&pitch->pitch map. Same thing for > GUI as by he MidiChannelPitchMapper. > IN: Midimessages > OUT: Midimessage > GUI: Widget to edit the map Yes. See above. > - MidiArpegiator: Just what the name say. The arpregiator starts playing > when a noteon comes in. It stops playing when a noteoff commes in. > Between this time all xxx secs a timer(or whatever) must activate > this modul so that it can send an other note according to the > sequence. How must such a modul be implement? Are there examples > for such a timing? > IN: Midimessage > OUT: Midimessage > GUI: Widget to edit the arpegiator. One instance holds only one sequence per channel. If > you want to have more then one arpegiator-sequence you must split your keyboard or > use conditunal modules for this. Yes. Thats fine. You see. It's the same as above. Arts needs to be capable to pass nicer data structures between modules (such as arpegiator sequences). > - Midi"Begleitautomatik" (What's that in english?): > When a message with a note comes in, this modul generates > additional notes. This is usefull to make acords. E.g. if > note C2 comes in, it outputs C2,E2,G1. > IN: Midimessage > OUT: Sequence of midimessages. Would it work to give out the messages in > sequence ? Yes. Should be. All modules should be scheduled by timer tick, and so the "Begleitautomatik", which would be a pretty neat feature I guess, could be contain some kind of mini sequencer to do that work. > - Boolean-Modules: Implements boolean operations. > IN: Operand1, Operand2, Kind of Operation(Equal,Lower,Higher,And,Or,...) > Should each operation have an own modul ? Must this modules be implemented > different for each type? (as far as i see from the idl it must at the moment; > One port can only have one type) > OUT: Boolean-Result (true,false) What appears to be the question here is, what kind of booean, and what kind of inputs. Arts distinguishes properties and signals. I'll put you a description here what is implemented in the current flow concept. (Well I wrote that to describe why scopes currently are not there, but that may be useful anyway). .. Signal | from AS | from AB | from SD ---------+---------+---------+--------- to AS | ir | c | i ---------+---------+---------+--------- to AB | | p | i ---------+---------+---------+--------- Property | from AS | from AB | from SD ---------+---------+---------+--------- to AS | i | | i ---------+---------+---------+--------- to AB | | ip | i ---------+---------+---------+--------- i: internal handling r: realtime correctness during delivery c: CORBA transport p: partly implemented SD: structure description (the parameters that are hardcoded in the flow graph) AB: artsbuilder AS: artsserver Signals are supposed to be values which change constantly and are samples with a constant frequency. Properties are supposed to be values that may change every now and then, but rather not very often (number of channels of the Synth_PLAY module for instance). As you see, the delivery from AB to AS is implemented only for signals and there is no delivery from AS to AB _at all_. It might be a good idea to rewrite some parts of artsbuilder and artsserver completely to improve that situation. .. I think it should make sense to have booleans as properties, while perhaps operating on normal audio signals. For instance currently Synth_STRUCTURE_KILL requires a kind of a boolean information as input, that is "should I kill that structure right now?", which can be answered with yes or no. But currently this is implemented as audio signal, which makes each Synth_STRUCTURE_KILL do 44100 if(signal > 0.5) per second, which is certianly not optimal. Currently, audio data is passed as audio signal (type float), and strings are always passed as properties (type string). Booleans shall be passed as properties as well. Good - to find a conclusion here - you see the problem: the aRts signal & property passing mechanisms are by no means complete. They work more or less well for the modules that are there, and I didn't implement modules like boolean arithmetic or conditional stuff, or flexible envelopes or midi processing or scopes or whatever else, since they don't fit in the limited communication model very well. If you want all that (most things I suppose would be great to have), then you need to extend the communication model. One consideration might be to throw the implementations of the commuication in the GUI server and the implementation of the communcation between modules in the synthesis server together. Well - you need to look at the code and see whats reasoable to do. I am currently not working on these things (though I'll come back to that sooner or later, as the communication model really needs work). > - Compare-Modul: If IN is true, it will pass throu the first input, otherwiese > the second. > IN: Boolean-Switch,Input1,Input2. > Same question on types as by the boolean-modules > OUT: Result Yes. What also might be useful for tasks like that is conditional scheduling or something like that. If you use a compare module to switch between two waveforms for an oscillator you probably don't want both to be calculated always, and one of the results to be thrown away... > What do you think about this ? > Is the design idea ok? Are the names ok? > Are modules missing ? The design is good. The main point is that there are quite some things missing to implement that modules. But if you would have implementations of these ready (with reasonable changes in the communication model), then I suppose the missing modules would be found very fast. You see whats missing when you use it in daily work, and something just isn't there. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Thu Sep 16 20:35:31 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA26060 for arts-list; Thu, 16 Sep 1999 20:35:28 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id UAA26057 for ; Thu, 16 Sep 1999 20:35:26 +0200 Received: (qmail 8993 invoked by uid 0); 16 Sep 1999 18:36:43 -0000 Received: from host-62.96.51.244.inetservice.de (HELO gate.way) (62.96.51.244) by mail1.gmx.net with SMTP; 16 Sep 1999 18:36:43 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id UAA01532 for arts@space.twc.de; Thu, 16 Sep 1999 20:08:35 +0200 Date: Thu, 16 Sep 1999 20:08:35 +0200 From: Emmeran Seehuber To: Arts Mailing List Subject: JASQ (Jet another silly question ... :-) about midisend Message-ID: <19990916200835.A893@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 272 Lines: 10 Hi ! realy silly question - but what is the version of midisend ? cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Thu Sep 16 21:09:24 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id VAA26144 for arts-list; Thu, 16 Sep 1999 21:09:22 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id VAA26141 for ; Thu, 16 Sep 1999 21:09:19 +0200 Received: (qmail 808 invoked by uid 0); 16 Sep 1999 19:10:35 -0000 Received: from host-62.96.51.54.inetservice.de (HELO gate.way) (62.96.51.54) by mail2.gmx.net with SMTP; 16 Sep 1999 19:10:35 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id VAA02192 for arts@space.twc.de; Thu, 16 Sep 1999 21:06:21 +0200 Date: Thu, 16 Sep 1999 21:06:21 +0200 From: Emmeran Seehuber To: Arts Mailing List Subject: Midisend patch Message-ID: <19990916210621.B1873@gate> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 6428 Lines: 103 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Hello ! attached you find the patched midisend. Is the description understandible? -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== --k1lZvvs/B4yU6o8G Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="midisend.tgz" Content-Transfer-Encoding: base64 H4sIAFA64TcAA+1be3PayLLff6NP0SGVG3BkDI6T3IDtewm2s1TFj8J4c1PZlEtIA2gjNJQk sDkpf6vzAW93z4wegB/JJjmnTjHlsmHU09OPX/f0jMZj3/NjEXpV1/3tZ7V6rfZqZwd+A4DX r9Tfuv6ObXv71euXAK9ev65tv9h5WcfP9fqrWv03qP00iXJtGidOBPCbGI/nd9OJKP4VAv3a trVhWW05mUf+cJRAuV2B+ps3b+BwPBaRE8K5EKNpX0QWLLdkJC7Jav87HF9XPWFZvZEfwySS w8gZA34cREJALAfJlROJJszlFFzkGQmEXBL5/WkiwE/ACb0tGcFYev5gbmHHNPREROwhEdE4 BjngL+9OLuCdCFGuAM6m/cB34b3vijAW4OC81BOPhAf9uUXkRzT7uZ4djiRydRJfhk0QPj6P YIYOxe+wbSbQ3GyQkVV2EhI4AjmhQRWUcg6Bk2TjqssKZ3p54IfMcyQnqMYIuaFiV34QQF8A YmkwDWwLKeFDp/f76UUPWicf4UOr222d9D42kTIZSXwqZkLx8ceTwEe2qAz6JZmjzNbxYbf9 O9K33nbed3ofUWw46vRODs/P4ei0Cy04a3V7nfbF+1YXzi66Z6fnh1UglxJH6w5zDtgdaDVP JI4fxKjqR3RejCIFHoycmUAnusKfoUAOuAif+31kOYEMh6wYUmZ2a4I/gFAmNlxFPgIikbDk PSvzng2d0K3aQDnj2IljaM3QYW1n3I98b4gfj1tQ266/eGPDxXkLBd/YsiwEOUB75IRDETfw Y/1VtfamWgB6CT/MSyneYXcB3fscAZvQQT+IsQgTQU4eO5OJj1qh9i6yD0UQE5xh4ifuSKDd 1KCuuJLRF6RXYIKJgwgKhzbqfYVgIA5DkeDDcqUKOtROZCIa0ENTILUzRuClgaAth5HBrnBZ MQ8eG103NqCAzCsMD4SjxBj3Q3RMfw4Hzsz34F0VzgM59hHLOKaTMGUkAuHEyE97QrvxQI4d YhJCfWv75dabN1We7okfusHUE1Aam5VkVLIsV4ZxQpJFG3DcOeicH54cXP5x2D3vnJ7AHpT+ qFfrUM78UCk1LcsPMUrCyTS5HHhItFm3MQEgmz2o2RR1fYnYxC9NixiDe+QH4sQZi0/12vbL z00ej0Z0R02rfYzSHDsTxMgEOc8kajuNnaEo89ANMk3F+mo9GkwiHDYoxwnmnMgu/RmWKs3l 7gsa24CnMXyCzQHskrKemCG09+Ez9Y2xz5kMUCLdMVN/EtgNpJxgJ3K2edoV7AklA5VSIWNN HoiE46kEQIbBlCrH1VtkNHn5QAycaZBQQtpCRlvEsAqdASfgeCJcTLMYtp4Tj2zKSkiHLPxQ sQVYJdzYCKd0JMkC6XjVu8bM8JfxGuYyFP9O8oSmIHfjQiCqOotgB4pK3YoD4c8YqT+N7+IX 4C9OOd/H9JG49pNyHT/daPxQ1IpWNIzLBDQnGrq2QvgGfZkRnAC2tjCHJNMJpk72AnbhmuBO 5uUUrnYpdQtNZD26GuGTcpmhi/jWqYAnIMZ2adwYNGZJUKpUYB9qFesRAvdRfEVJRo3CLu57 5GLkwrPxswZm1TI8RvRXCUH4lwiRWwUqsGIxXzTg07hBa/WzRAGQff40fkwYJpE+1T7bml+T pn3UR7IvzUyCBCXQsVtfTRFkFNsFCiWQIpohURb49SZoMUsU3ueYbFAokmk5x1SaqZaLMw+Q KfokLDpFqWNjKtlZ0kn7sqFTiLbAItmNhT8IFsyJAxwB7dPj49OTy7edk1b3IycnkyIvKZUu oAg2mO3nivUEVxGh6O8mC7FgYtDB1gY7FZHYPu2+bWGy8BPfCfx/8JrJyxAla/zDzxsN/H05 Q24y6qNhc500UkGPQW1TXnflZiBdJ9hEahVvZsTb0xaz6UsH2eDjzX3qupMJ0jLsc8L0/xJu ouTp/2UY9f3QK5c6B+8b5Oy2Wl4b9WoN3a19W/JDkTSY7UjGSeO/sRneWFWUNX8/vgz9oIy8 Kwr8X62VqAeEPSSRxAUPc/2JZH/pdV0bVrKoWCBhPYJo5JUSaAeRQCkLqxJ+j3G/gNCt5kIm xSSnlsP/6/Quj1qd9xfdQ/XkhgXPacsmUUKgVfJmaFyGWAjKK1ZKKcxFDkGAYkEvF7fjIEtm aZ5RQmDeoLCs5O1EucSEYSVV08TiRERYMI59k2qr1TTPU5uGsT8MsZ7gZOzbY+d672WtVmtm zGnY3t52BQF/TfmglnuMrMv+Xq3p4/p63fSfPzcCfM3srUy0uY9lpDgNy1gtvKo9L/tP69sV G3D3mUsGRdrBoECc0t3kHVXLe2eFKYwdkmjONpBYhGDVjlhCSyBY0xwDBppZjUOUuSR0etk9 OD15/zHFcDmjpYKocgd6sXTJw1dlb5ZEYUHVFI+/CY/0DJPRXVqD/PJYuXsBhVQtUumTRx3y 0WwWuPQFlqYhmY+GZBCy8gDi/DeOh59efFZPeOHEMrJgFnIwEnVx3UqtZ9OwVF21ckJZU74T ybGIKbP35hNRJsoVGOO1g0Lr+Pzd5clp7/Dy9OioUVhKabXFAuk4Hpbz063GXTa5jmkeY0PW f8brO4tTZFXwxuJqbix6ouZpgGYPT9EKzBKevvB40bxFhAdIUFiqVxvn5HttE36TaezFYiYj +kPgyuAn83tNeJcFQ7jFgjYY/vB0+057rjo7gdXKPEz4gvVvVKRidtra2vyGhuS8uzRb2DiZ DgbfysPqS4lLo95sNRqm1sxv/ybxP0x+UyXysu2NxWk4yWJ2GSqFsm3zXDj4jzrvD2GDyfZw kaA8mqOxS5FagbgMZirt5gir8yiEgYN5jRmpveRb1F5EtJPceV7/3NT9LP17rDKYFRZiIX1R e1CdfspQ1jQkB9bucVkz41rSprkrVHWrXMIMnj9X3uNFmDoMCzuvApOyEuTjgRugwcrMjuXW iiTRVGR7lMwVKMmJuE4+yMjjPe/Gfxld9K6Fv9PjdONy5EfotfiLPwEnCCDQ3ugHTvgltkEk LuVydnm/LUMq3dXsxhTcazRVdv1dBBOk28jZ0STgsn6qU5jJtZxLarg5GGF9A+3D02lyOmAj VZok5Slt2AYQYE9hrwBY1hc6/gyfNYod0WIHbVO0ZOgTHVg0yTuJy3iI9mM19KB0G2C0VyDK DTuR4fnEcflMJuLDws19IBsDL3AxjEQk1KnQjfarMj1F4hXRcS2p6PCJ9hBOldpP0bdw6xPK KxuGUh/T0GZInw8RI/bUz3dSwZz2gnmbC9+/10MbqYs48m43/91eW3J0zg/L8ZPFZiERYPAU cxvKMvCHFLS2yhCqgxOCiqyUlFxpHIgpHnfVFG/sdu05DWqsJLWl81GcyxEctiYzuA77KRcp abbBiTrDkE5yOYiZv4Kfyh6KhZLonOLelWM63Ix15txIAbgHz5480znUjNVEdL4xnpQ1qV06 67ZLFRpRS+XIFLpfJWpsyNPIH5qldw+cRAblRboH8zrnLdrf5XIYen+bxz0a6e0mQjD+lLfA 52puZP5Bfp/EM/hEwPo28fPuHouNHzF6KrmC9vaJ9JOuGNMzH2dWRc8e+M3vGp4TfEHoGyv7 rWCcQ3EmrakPzPlJA8oIMtwu+jEfnvMJueAjcifBqqHx1DNFQy48c5FZaeYmXgiF1ZA+WEP6 Vh4MjwN/MPg3BjW/kfleSC8O7sl0ODzP6X87rFdm51uAffArgd3798vVxrZ/j0tP/qxM+9DU pxTJYU19+G42OalS5ZpLSHtwAu390gTaO/uPxdmdfH4CyvLZ6LsxtpJJpov5uIyvb8hkvbOf hLDlyS7CL7gdCrl+pRfwD55jufDXp1Rv54nY4GNDsz2mkp3uZFCh7jmJo65JqOMTa6m6W30Y lJ4jGEOvOgYye4ROTHNFdIcGTTfSh8s4I8/MlyjM24n/0XGXc3h1QC9QjEQVeLxXeIpmK1fy G4W9ffgocJufIBF4Evykapln7a0zet7m7wvzfApXJy49P6u1OPutY4xUGlXaOucFI9oPYLSU NfVZck6Zs3uUyUXIA1XJjyiaN69J6udb9LgrMnNBQXvWH3D/K7u18QOY3dLuvv8HO6+2X5v7 f/Wd1zt0/29ne33/75e09f2/9f2///T7f0/8QUgXMtJLIr9bT/A7FTC5ruwq2y5dh5LV0X6x K/D7i31YhwyLfdMQMeAt0M3jrYEbJgF1L9yY609jujCXEc+Em8goP9yXOJFwxjgWK1IRhVBq lwCrkiInXFGI042+7sjYdAMykSdFbG5vmeuKhIC0PixcWiSLqXHpJbqvFkeXS2ez6gUv0OvV 2IDcvK/Jvb2oaiqq22LodS8ObXJ0PHVdEceI/oAocCr9QuG+N0fNbGpaL3naoU/RMVbvbsFx XSy8dZFk6QSFvcnUUezp5BYLv2mUXobg6bn8Wyr6sFzAKnOGAZ9T+ozOhGOGfI5Teqqasfsh h8eqDFQzY32odObTbXVkrN6DmGPjqnphEqeai2tXqOumuYqdnaCKSoRHqA3Fsc5MtUOVRvys pR6Q4IhsTsb0cohS1581G2J63cFvO1yEpk2H/gQmHvrMfsZ/+Zd5SeYrPSYS9aUsr8JdXaFJ cQlaJQbxYBq6rAevEL4oMKga5nxMvZo539ZJ34pkXvqGV2QEP4zCqZsU9j9fb5oZTDJvHWH+ FA7W96Y8l6Q4et4JXaG05EuXxG8aKYXFNZtXOyBfqdPF3JEMvGIM+yFdumEA8njK2aaITNU0 ImfcdEGa36zoyrhIywVodgEo3bKsOsvWRWmRz1laxt7HpbjV1FyS+URQzsbxu0hl58XaLwjJ N3xpyEInFDYEzZVcMyH3cwKnHAtdkCvMeSdKv24Rkyy9nze7ZlnsyXsZd6J0g0Zd6oMfUdk/ rKX1f3Kd/Kw57qn/X7x4kdb/L15y/b9dq6/r/1/SjP/NGo5p7ENaovGibsp2yl8c2ekQWmdV 1Z5en9aLcYzVHF1adCV2UE6je+tgcUFNZBMZJVV1/SQbBPo8g/6XoS8wnwlL3U6f8KFLJKfD Ec3pdHtUkWZiGglFdVjFBSnwden+Rcz70qGsb9FUrI1Py3dM1TTtGlzf524sizHJ5tc48yIU rDJrot/Lc/nqwD+f/LPCNZOmxI+Yp9+m71hxElxRLZ/fvXpVaHmeT5kaKxFeMFXBlTh9RegE sQRDbFnvAokGiRrWpspADbOuhdMx/W+KXvXptpT5jKqiPSXQQQVVBsr+dFSmijpyb1y0iq0X 3dSdrNvmDGc1t0z1fwuYJVchgMyCa1LIfmDbU453TDKjpIg+CvPUavtALsIo0ktyEMgrWseM +WiUKatEKhTCURuhS8AgIiMcZ+gPI6wAHaUlXePf1U/3U+jZbGoFJL24ct2ozhWJqZ1fcY1B SYC0tDT7NoPORPLo3fQYfp9W3PN5mDjXSq6zbjuTxd49QvizFvhZL3f8yVAsaEnvkrBEo2LB 0cj5kerupi+s1CT7HBWel/3PD0+wrNPB/Totsk41I3Quu05pokbtL2lkVMr5h4cu+6PgC1gU vFdwxh3mJyFVyD1UxJyETHiHfIrDkmxnq2XT1JZ17lCyihtWK44xnND9JoJVxO68oY6Yw18l P50QFA2CwEquJG1JEkrLXPtzcUo9uJmnXASST0S0jW2u7hETlv7HmJguL0s3cWivTRF/xQcB GMwUn5ubFsEdNwN1G17ixhvqFmEl69jeYSpL/w/SX1O69uKESlJ1C2aS1f+Z7LTAoBmpenZ4 dtzKXoW3iZCfcbO+zb3/6uV13dZt3dZt3dZt3dZt3dZt3dZt3dZt3dZt3dbtX9r+HyIU92oA UAAA --k1lZvvs/B4yU6o8G-- From owner-arts@space.twc.de Fri Sep 17 16:44:22 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id QAA28244 for arts-list; Fri, 17 Sep 1999 16:44:03 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by space.twc.de (8.8.7/8.8.7) with ESMTP id QAA28241 for ; Fri, 17 Sep 1999 16:43:59 +0200 Received: from zeta.org.au (d14.syd2.zeta.org.au [203.26.11.14]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id AAA03144 for ; Sat, 18 Sep 1999 00:45:00 +1000 Message-ID: <37E268F5.1C427A39@zeta.org.au> Date: Sat, 18 Sep 1999 01:44:45 +0930 From: Tim Docker X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: midi_main.arts ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 346 Lines: 11 Hi all, Congratuations , arts looks like a really slick piece of software! One question though: The documentation (specifically the bit about getting cantor up and running), refers to the file midi_main.arts. I can't seem to find it in the arts 0.3.3 release. Presumably it is a demo of how to use the midi intrument mapper. Any pointers? Tim From owner-arts@space.twc.de Sat Sep 18 10:51:30 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30570 for arts-list; Sat, 18 Sep 1999 10:51:08 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30565; Sat, 18 Sep 1999 10:51:07 +0200 Message-ID: <19990918105107.53983@space.twc.de> Date: Sat, 18 Sep 1999 10:51:07 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: JASQ (Jet another silly question ... :-) about midisend References: <19990916200835.A893@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990916200835.A893@gate>; from Emmeran Seehuber on Thu, Sep 16, 1999 at 08:08:35PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 710 Lines: 18 Hi! On Thu, Sep 16, 1999 at 08:08:35PM +0200, Emmeran Seehuber wrote: > realy silly question - but what is the version of midisend ? Really silly answer: there is none. Currently, aRts consists of artsbuilder, artsserver, artsserver.bin, artswrapper, artsshell, artsmp3, artscat, akaikggen, akaiparse and midisend. I thought that it would be perhaps too much work (and a bit confusing) to have seperate versions for all of them. So they follow the major release, e.g. in aRts-0.3.4, the arts builder will tell you, it is "Arts Builder 0.3.4". Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Sep 18 10:56:36 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30585 for arts-list; Sat, 18 Sep 1999 10:56:35 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30580; Sat, 18 Sep 1999 10:56:34 +0200 Message-ID: <19990918105634.45006@space.twc.de> Date: Sat, 18 Sep 1999 10:56:34 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Midisend patch References: <19990916210621.B1873@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990916210621.B1873@gate>; from Emmeran Seehuber on Thu, Sep 16, 1999 at 09:06:21PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 713 Lines: 20 Hi! On Thu, Sep 16, 1999 at 09:06:21PM +0200, Emmeran Seehuber wrote: > attached you find the patched midisend. > Is the description understandible? One thing (forgot that in the version reply), if you want to have the aRts version, #include "config.h" and use VERSION. You can check if there is a config.h, by checking for #ifdef HAVE_CONFIG_H. Another thing is: you shouldn't use exceptions. Some compilers don't like them, and aRts should currently build without. Can you make a version without them? The description is good as far as I see. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Sep 18 10:59:36 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30600 for arts-list; Sat, 18 Sep 1999 10:59:35 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id KAA30595; Sat, 18 Sep 1999 10:59:34 +0200 Message-ID: <19990918105934.08656@space.twc.de> Date: Sat, 18 Sep 1999 10:59:34 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: midi_main.arts ?? References: <37E268F5.1C427A39@zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <37E268F5.1C427A39@zeta.org.au>; from Tim Docker on Sat, Sep 18, 1999 at 01:44:45AM +0930 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 742 Lines: 18 Hi! On Sat, Sep 18, 1999 at 01:44:45AM +0930, Tim Docker wrote: > One question though: The documentation (specifically the bit about > getting cantor up and running), > refers to the file midi_main.arts. I can't seem to find it in the arts > 0.3.3 release. Presumably it is a demo > of how to use the midi intrument mapper. Any pointers? Well, great to hear that there are actually users that _read_ the documentation. No, there is no longer a midi_main.arts, but any example with an instrument mapper (that Channel/Instrument/Destination list with the "Add" button) will do. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sat Sep 18 23:56:33 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA00081 for arts-list; Sat, 18 Sep 1999 23:56:24 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA00078 for ; Sat, 18 Sep 1999 23:56:19 +0200 Received: from zeta.org.au (d11.syd2.zeta.org.au [203.26.11.11]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id HAA21530 for ; Sun, 19 Sep 1999 07:57:14 +1000 Message-ID: <37E41FC5.173BB46A@zeta.org.au> Date: Sun, 19 Sep 1999 08:57:01 +0930 From: Tim Docker X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: A few more arts questions Content-Type: multipart/mixed; boundary="------------578B3353128DD7131C569AB8" Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2286 Lines: 88 This is a multi-part message in MIME format. --------------578B3353128DD7131C569AB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thank for the pointer on midi-main.arts I worked out the midi mapper in one of the examples. There was some confusion where midi channels are numbered from zero (in the midi-protocol), but from 1 in the dialog. I don't actually have any hardware for doing midi (yet), but got the midi bus stuff working by writing some python scripts to send events down via the idl interface. This worked pretty well. One day I'll have a got at getting python to control structures in the synthesiser directly. FYI, a trivial script is attached below. I don't have to do too much to run up to 100% CPU and blow the thing away though. Clearly my P133 is not up to the job - how fast are the machines that users are generally running this stuff on? I was surprised at first to see that all the signal processing is done in floating point. Obviously the (virtually) unlimited dynamic range makes things much easier, but I thought the overhead would be too high. How much slower is floating point than integer arithmetic on current processors? I was thinking of creating some modules for my amusement. One that I think would be useful would be an arbitrary transfer function. This could be used for control purposes,signal processing as well as arbitrary waveform generation. /home/Would this be of interest for incorporatingback in the main distribution? Cheers, Tim --------------578B3353128DD7131C569AB8 Content-Type: text/plain; charset=us-ascii; name="test2.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test2.py" import sys,os,time from Fnorb.orb import CORBA from _GlobalIDL import MidiChannel def getChannel(orb): f = os.popen('./midiChannel', 'r') stringified_ior = f.readlines()[0] f.close() return orb.string_to_object(stringified_ior) def main(argv): orb = CORBA.ORB_init(argv, CORBA.ORB_ID) midi = getChannel(orb) while 1: for i in [0,2,4,5,7,9,11,12,11,9,7,5,4,2]: midi.noteOn( 0, 0x40+i, 0xff ) time.sleep(0.5) midi.noteOff( 0, 0x40+i ) time.sleep(0.25) main(sys.argv) --------------578B3353128DD7131C569AB8-- From owner-arts@space.twc.de Sun Sep 19 20:25:00 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA02738 for arts-list; Sun, 19 Sep 1999 20:24:22 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA02733; Sun, 19 Sep 1999 20:24:20 +0200 Message-ID: <19990919202420.00693@space.twc.de> Date: Sun, 19 Sep 1999 20:24:20 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: A few more arts questions References: <37E41FC5.173BB46A@zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <37E41FC5.173BB46A@zeta.org.au>; from Tim Docker on Sun, Sep 19, 1999 at 08:57:01AM +0930 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 3794 Lines: 90 Hi! On Sun, Sep 19, 1999 at 08:57:01AM +0930, Tim Docker wrote: > [...] > > I don't have to do too much to run up to 100% CPU and blow the thing > away though. Clearly my P133 is not up to the job - how fast are the > machines that users are generally running this stuff on? I am running aRts on a PII-350. But the problem is always the same. Of course I can do some mixer channels, play some wavs and do some nice synthesis voices. But you always want more. > I was surprised > at first to see that all the signal processing is done in floating > point. Obviously the (virtually) unlimited dynamic range makes things > much easier, but I thought the overhead would be too high. How much > slower is floating point than integer arithmetic on current processors? Floating point is faster on my processor for instance. I've put the program I used to measure that online at http://space.twc.de/~stefan/fl_int.c, so you can see for yourself. For me, the results are: test 1 - 3.65 seconds (add floats) test 2 - 3.68 seconds (multiply floats) test 3 - 4.81 seconds (add longs) test 4 - 14.26 seconds (mul longs with dividing for fixed point arithmetic) Forget test 4, perhaps one can tune that, but of course you need to do some kind of correction when multiplying two longs, because you'll have fixed point arithmetic then. Well, but there is something else that isn't quite optimal yet: the scheduling overhead. When test1 takes 3.65 seconds, that means, that 350000000*3.65/(64*4000000) = 4.99 cycles are consumed by this add operation. On the other hand, I clicked 300 aRts modules in a network (well, I created a structure with 6, then 10 of these, and then 5 of these). That took around 72% cpu load, that means: 350000000*0.72/44100/300 = 19.047 cycles. Of course, that might be a result that is caused by the much much higher memory consumption, which might lead to a far worse caching efficiency. After all, this will consume 230400 bytes of memory (while the other example only has one block). But on the other hand, the aRts flow graph evaluation algorithm currently always watches out for feed back loops, and it might be possible to save quite a bit of performance by reconsidering how to make the algorithm more smart and rewriting it. I'll do that sooner or later. Well, but of course, there are disadvantages of floating point arithmetic, namely for instance conversion from and to integers (if you load a wav file, you get it as integers, and if you want to lookup your sine wave in a table, you'll need integers, too). Making aRts able to handle both, floating point signals and fixed point signals so might make it faster for specific tasks (like emulating a sampler). > I was thinking of creating some modules for my amusement. One that I > think would be useful would be an arbitrary transfer function. This > could be > used for control purposes,signal processing as well as arbitrary > waveform > generation. /home/Would this be of interest for incorporatingback in the > main > distribution? Well, yes. I don't quite know how you want to define that function. What would be possible, is taking a string as input, like "sin(x)^2", and builing a table from that, and then doing interpolated table lookups when doing the actual computation. I will happily include any module that is somehow useful (that is mainly, you can't achieve the same functionality by using a signal graph of two or three other modules), working, fast enough to use it a few times in the signal flow and documented. By the way, the python thing is nice. I think I'll include it in the documentation, if you don't mind. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Sep 20 23:31:34 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA06237 for arts-list; Mon, 20 Sep 1999 23:31:27 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id XAA06234 for ; Mon, 20 Sep 1999 23:31:26 +0200 Received: (qmail 32497 invoked by uid 0); 20 Sep 1999 18:39:31 -0000 Received: from host-62.96.50.234.inetservice.de (HELO gate.way) (62.96.50.234) by mail2.gmx.net with SMTP; 20 Sep 1999 18:39:31 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id TAA01183 for arts@space.twc.de; Mon, 20 Sep 1999 19:07:15 +0200 Date: Mon, 20 Sep 1999 19:07:15 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Midisend patch Message-ID: <19990920190714.A940@gate> References: <19990916210621.B1873@gate> <19990918105634.45006@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <19990918105634.45006@space.twc.de> Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 654 Lines: 17 On Sat, Sep 18, 1999 at 10:56:34AM +0200, Stefan Westerfeld wrote: > One thing (forgot that in the version reply), if you want to have the > aRts version, #include "config.h" and use VERSION. You can check if > there is a config.h, by checking for #ifdef HAVE_CONFIG_H. Ok. > > Another thing is: you shouldn't use exceptions. Some compilers don't > like them, and aRts should currently build without. Can you make a > version without them? Yes, is attached. -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Mon Sep 20 23:31:34 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA06232 for arts-list; Mon, 20 Sep 1999 23:31:20 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id XAA06229 for ; Mon, 20 Sep 1999 23:31:17 +0200 Received: (qmail 32323 invoked by uid 0); 20 Sep 1999 18:39:20 -0000 Received: from host-62.96.50.234.inetservice.de (HELO gate.way) (62.96.50.234) by mail2.gmx.net with SMTP; 20 Sep 1999 18:39:20 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id TAA01386 for arts@space.twc.de; Mon, 20 Sep 1999 19:47:41 +0200 Date: Mon, 20 Sep 1999 19:47:40 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Midi-Channel splitting & Co. Message-ID: <19990920194740.B940@gate> References: <19990911183256.A3604@gate> <19990912222803.49003@space.twc.de> <19990913215556.A23343@gate> <19990916193100.20491@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <19990916193100.20491@space.twc.de> Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 4402 Lines: 99 > [..] > I have a special midi router, which can route mapped instruments. > > The standard scheme for a router is: each time a key is pressed, a structure > is created, which gets frequency, velocity and a "pressed" flag. That > structure may for instance just play a sample (with Synth_PLAY_WAV), or > synthesize something, or ... > > Mapped routers allow to pass additional arguments to the structure, depending > what the pitch of the note was, so that you could use one sample for one > range of keys (or a single key), and another for the next range of keys. > > Thus, you can (if I do wave resampling, for akai that works) for instance > have a piano, that is playing & resampling different samples on different > octaves, or for instance have a drum map. > If i understand right, it does something similar as my patched midisend (Splitting the incomming pitch on different instruments). But it just do it on channel level, it does it on instrument level. > There might be two useful ways to go: either, you derive of ArtsServer, and > implement a whole new flow server for midi flow, that will run besides the > synthesis server. > > This will allow you to do an independant concept of base classes, > communication and scheduling for midi events. Of course you get problems > then when writing modules that should have both, signal flow, and process > midi events (such as a thing that converts a midi controller into a signal). > > The other way is extending the internal communication model which is used > during scheduling to handle midi event based communication as well. That is > mainly changing SynthModule and Synthesizer_impl::Run (but not only). More > about this below. > I think the only right way is to extend the existing arts communication flow. I've took a deeper look in the arts source. It seems, you've put realy some known how about realtime synthese in it ... :-) I think, it will take some time to get into arts. - In two weeks i've got three weeks holidays, and nothing to do yet ... :-) > [..] > I think a nice (but complex) solution would be: > > Extend property passing to pass not only audio_data and string_data types, > but also to pass composed types like midi events, samples, such maps you talk > of, envelopes (think of fasttrackers panning or volume envelopes) etc. > > All that needs to be done for aRts sooner or later anyway. > > A less complex solution might look like current midi mapping code: > > 1. You have a synthesis module, which performs one mapping operation and > has that specified as parameters. So Midi_CHANNEL_PITCH_MAPPER might be > > INs: midimessage, channel, pitch, newchannel > OUT: midimessage > > 2. You have a gui module, which creates a battery of > Midi_CHANNEL_PITCH_MAPPERs, one for each mapping operation. > > The second solution may be easier to implement for one or two more affected > modules, while the first solution could be the generic solution for every > module that needs more complex data structures as parameters. > I'd like to try to implement the first one. > > - Boolean-Modules: Implements boolean operations. > > IN: Operand1, Operand2, Kind of Operation(Equal,Lower,Higher,And,Or,...) > > Should each operation have an own modul ? Must this modules be implemented > > different for each type? (as far as i see from the idl it must at the moment; > > One port can only have one type) > > OUT: Boolean-Result (true,false) > > What appears to be the question here is, what kind of booean, and what kind > of inputs. > > Arts distinguishes properties and signals. I'll put you a description here > what is implemented in the current flow concept. (Well I wrote that to > describe why scopes currently are not there, but that may be useful anyway). > [..] > Well - you need to look at the code and see whats reasoable to do. I am > currently not working on these things (though I'll come back to that sooner > or later, as the communication model really needs work). > I've not realy checked all of this yet - But i think it gets cleaner as i look at the source. As soon as i've checked it out, i'll post what i think is to change to make all this possible. cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Tue Sep 21 00:24:47 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id AAA06978 for arts-list; Tue, 21 Sep 1999 00:24:45 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id AAA06973; Tue, 21 Sep 1999 00:24:44 +0200 Message-ID: <19990921002444.11291@space.twc.de> Date: Tue, 21 Sep 1999 00:24:44 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Midisend patch References: <19990916210621.B1873@gate> <19990918105634.45006@space.twc.de> <19990920190714.A940@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990920190714.A940@gate>; from Emmeran Seehuber on Mon, Sep 20, 1999 at 07:07:15PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 455 Lines: 13 Hi! On Mon, Sep 20, 1999 at 07:07:15PM +0200, Emmeran Seehuber wrote: > > Another thing is: you shouldn't use exceptions. Some compilers don't > > like them, and aRts should currently build without. Can you make a > > version without them? > Yes, is attached. Where? I didn't get anything? Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Tue Sep 21 15:10:07 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA11819 for arts-list; Tue, 21 Sep 1999 15:10:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA11816 for ; Tue, 21 Sep 1999 15:09:54 +0200 Received: from zeta.org.au (d66.syd2.zeta.org.au [203.26.11.66]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA23117 for ; Tue, 21 Sep 1999 23:10:57 +1000 Message-ID: <37E798EC.695D519A@zeta.org.au> Date: Wed, 22 Sep 1999 00:10:45 +0930 From: Tim Docker X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Re: A few more arts questions References: <37E41FC5.173BB46A@zeta.org.au> <19990919202420.00693@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1287 Lines: 34 > > Floating point is faster on my processor for instance. I've put the program > I used to measure that online at http://space.twc.de/~stefan/fl_int.c, so > you can see for yourself. > .... Looks like you've looked at this in a bit of detail. I'm pleased that floating point turns out as fast or faster. > > Well, yes. I don't quite know how you want to define that function. What > would be possible, is taking a string as input, like "sin(x)^2", and > builing a table from that, and then doing interpolated table lookups > when doing the actual computation. > > I will happily include any module that is somehow useful (that is mainly, > you can't achieve the same functionality by using a signal graph of two > or three other modules), working, fast enough to use it a few times in > the signal flow and documented. So far I've created a noise generator, a state-variable 2nd order filter, and a transfer function. The latter is provided with endpoints of lines, and linearly interpolates on the lines. It's of more use for control signal processing rather than waveform generation. > > By the way, the python thing is nice. I think I'll include it in the > documentation, if you don't mind. Sure, If I get a chance, I'll try to put together some more examples. cheers, Tim From owner-arts@space.twc.de Tue Sep 21 15:40:08 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA11994 for arts-list; Tue, 21 Sep 1999 15:40:06 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA11991 for ; Tue, 21 Sep 1999 15:40:02 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id PAA27559 for ; Tue, 21 Sep 1999 15:41:29 +0200 (MET DST) Date: Tue, 21 Sep 1999 15:41:29 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: A few more arts questions In-Reply-To: <37E798EC.695D519A@zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 393 Lines: 11 > > So far I've created a noise generator, a state-variable 2nd order filter, and > a transfer function. The latter is provided with endpoints of lines, and > linearly interpolates on the lines. It's of more use for control signal > processing rather than waveform generation. > A filter with adjustable Q (up to self oscillation) would be good news. Can't build a synth without. Reiner From owner-arts@space.twc.de Tue Sep 21 16:53:31 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id QAA12413 for arts-list; Tue, 21 Sep 1999 16:53:24 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from netscanuk.com (root@netscanuk.com [209.176.31.30]) by space.twc.de (8.8.7/8.8.7) with ESMTP id QAA12410 for ; Tue, 21 Sep 1999 16:53:18 +0200 Received: from mother.software-superstars.com (localhost) by netscanuk.com (8.8.5) id PAA26521; Tue, 21 Sep 1999 15:52:22 -0400 (EDT) Received: from 192.168.1.2 ([192.168.1.2]) by mother.software-superstars.com (WinRoute Pro 4.0) with SMTP; Tue, 21 Sep 1999 15:51:36 +0100 From: "Andy Mucho" To: Subject: RE: A few more arts questions Date: Tue, 21 Sep 1999 15:50:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 932 Lines: 36 > -----Original Message----- > From: owner-arts@space.twc.de [mailto:owner-arts@space.twc.de]On Behalf > A filter with adjustable Q (up to self oscillation) would be good news. > Can't build a synth without. Try this. It's a really nice 4pole. Very Moog like. double MoogVCF::run(double input, double fc, double res) { double f = fc * 1.16; double fb = res * (1.0 - 0.15 * f * f); input -= out4 * fb; input *= 0.35013 * (f*f)*(f*f); out1 = input + 0.3 * in1 + (1 - f) * out1; // Pole 1 in1 = input; out2 = out1 + 0.3 * in2 + (1 - f) * out2; // Pole 2 in2 = out1; out3 = out2 + 0.3 * in3 + (1 - f) * out3; // Pole 3 in3 = out2; out4 = out3 + 0.3 * in4 + (1 - f) * out4; // Pole 4 in4 = out3; return out4; } in[x] and out[x] are member variables, init to 0.0 the controls: fc = cutoff, nearly linear [0,1] -> [0, fs/2] res = resonance [0, 4] -> [no resonance, self-oscillation] Regards AndyM From owner-arts@space.twc.de Tue Sep 21 21:03:15 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id VAA14136 for arts-list; Tue, 21 Sep 1999 21:03:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id VAA14133 for ; Tue, 21 Sep 1999 21:02:56 +0200 Received: (qmail 14616 invoked by uid 0); 21 Sep 1999 19:04:16 -0000 Received: from host-62.96.50.1.inetservice.de (HELO gate.way) (62.96.50.1) by mail2.gmx.net with SMTP; 21 Sep 1999 19:04:16 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id VAA00843 for arts@space.twc.de; Tue, 21 Sep 1999 21:12:41 +0200 Date: Tue, 21 Sep 1999 21:12:41 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Midisend patch Message-ID: <19990921211241.A827@gate> References: <19990916210621.B1873@gate> <19990918105634.45006@space.twc.de> <19990920190714.A940@gate> <19990921002444.11291@space.twc.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=C7zPtVaVf+AK4Oqc X-Mailer: Mutt 0.95.7i In-Reply-To: <19990921002444.11291@space.twc.de> Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 5518 Lines: 92 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Hi ! > > Yes, is attached. > Where? I didn't get anything? Ups, forget to attach it :-( cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== --C7zPtVaVf+AK4Oqc Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="midisend.tgz" Content-Transfer-Encoding: base64 H4sIAJBp5jcAA+1ae1MayxI//2Y/RYeURzArgjHmBqL3EtSEKgUL8ZybyklZyzILc7LsUrsL ykn53W93z+wLkUQryX0xZSHM9vT049c9PbMzlgMZCm9Qtu1fflSrVir7e3vwCwC82lf/q/o3 tt0XlUoFYP/Vq+re/t7L3V18Wn25v/cLVH6YRJk2DSMrAPhFjMfz1XQiCH+GQD+37WwZRtOf zAM5HEVQbJag+vr1azgej0VgeXAhxGjaF4EBd1s0EldktX8MxzflgTCM3kiGMAn8YWCNAb86 gRAQ+k50bQWiDnN/CjbyDARCLgpkfxoJkBFY3mDHD2DsD6QzN7Bj6g1EQOwhEsE4BN/hH+/a l/BOeCiXC+fTvittOJW28EIBFs5LPeFIDKA/N4j8hGa/0LPDiY9crUj6Xh2ExOcBzNCh+Bt2 4wk0NxP8wChaEQkcgD+hQSWUcg6uFaXjyncVTvUagPSY58ifoBoj5IaKXUvXhb4AxJIzdU0D KeH3Vu9957IHjfYH+L3R7TbavQ91pIxGPj4VM6H4yPHElcgWlUG/RHOU2Tg77jbfI33jbeu0 1fuAYsNJq9c+vriAk04XGnDe6PZazcvTRhfOL7vnnYvjMpBLiaOxwpwOuwOtNhCRJd0QVf2A zgtRJHcAI2sm0Im2kDMUyAIb4fN1HxmW63tDVgwpU7vVQTrg+ZEJ14FEQEQ+3PGekXrPhJZn l01MFy/hzApDaMzQYU1r3A/kYIhfzxpQ2a2+eG3C5UUDBd/aMQwEOUBzZHlDEdbwa3W/XHld zgG9gF/mhQTv8GYB3YccAdvQQj+IsfAiQU4eW5OJRK1QexvZe8INCc4wkZE9Emg3Nagrrv3g M9IrMMHEQgR5QxP1vkYwEIehiPBhsVQGHWptPxI16KEpkNoaI/CSQNCWw8hgV9is2ACexrpu bUEOmdcYHghHH2NceuiY/hyOrJkcwLsyXLj+WCKWcUwrYspAuMIKkZ/2hHbjkT+2iIkH1Z3d lzuvX5d5umfSGQgH3jd+O75qdtonrXdX77HTs93pQEDB9j1HDsujgvEMFxnpGJln43jpwaeG 9DBCvMk0unIGcADbVRODP4zwa8WkiOv7iEv8UTdQ3QDsE+mKtjUWH6uV3Zef6jweDWiP6kbz DBmfWRPEx6RuGDMfNZ2G1lAUeegWmaVkfDGeOJMAhznFMMJ8E5iFP7xCqX63+5LG1mAjhI+w 7cAbknsgZgjrQ/hEfWPssyYOSqQ7ZupfBG9c359gJ3I2edol7AkhjkqnkLIm6wfCGqjgJ8Ng OvXH5XtkjHPykXCsqRtRMtpBRjvEsAwth5NvOBE2plgM2YEVjkzKSEiHLKSn2AIsE24cC6d0 JMlc3xqUV42Z4UfsNcxjKP5K8oimIHfjIiDKOoNgB4pK3YoDYS82Un8aruLn4genm8cxfSJu ZFSs4rdbjR+KWNEIhmGRgGYFQ9ukuAswbPDHjOAEsLOD+SOaTjBtshewC9cDezIvJnA1C4lb aCLjyfUInxSLDF3Et04DPAExNgvjmlObRW6hVIJDqJSMJwjcJ+E1JRg1Cru474mNUQub480a ZtQiPEX0lwlB+J8IkVsJSrBkIV804EZYo3V6M1IAZJ9vhE8JwyTSx8onU/Or07RP+kj2uZ5K EKEEOnaryynclGI3R6EEUkQzJEoDv1oHLWaBwvsC8wYKRTLBb8fdi1anDaV6otzihA7yQld4 eV8oLUzMIHt3VNEurOnMoRVfJLs18A8xEqfBZufsrNO+ettqN7ofOCfFSe6KsucCeGCL2X4q YXJ0cYVk+tVknEMJa7Czxb5EADY73bcNzBEykpYr/+Jlklceys/4j5/Xavh5NUNuftBHe2Y6 aaRCHGPZpMxs+9uub1vuNlKrMItHvO00mE3ft5ANPt4+pK6VTJCW0Z4Rpv+nsCMlT//PmFFf eoNioXV0WiMfN9WKWquWK+hl7duC9ERUY7YjP4xqf8MW88ZCoqj5y/DKk24ReZcU5r8YS8EO iHaIAh/XOEzxbZ/9pZdybVifRcWaCEsQBCEvjkCbhggKaTQV8HeIWwREbDkTKQkmOaMc/7PV uzpptE4vu8fqyS0LntGWTaKEQKtkzVC78rD2869ZKaUw1zUEgbPWUUuvEvfjIM1hSXpRQmC6 oGgsZe1EKSSOvlKiZhyCExFgjTiWcYYtl5P0Tm3qhXLoYQnBOViaY+vm4CXu8uopcxp2cLBb QsDfUBqoZB4j66I8qNQlLqs3dfn8eSzAl9TeykTbh1g5io5XxCJhv/K8KDequyUTcMOZSQZ5 WsfJESd0t1lHVbLeWWKK2A5RMGcb+Fh7YKGOWEJLIFiTHAMxNNPShigzSahz1T3qtE8/JBgu prRUB5VWoBcrlix8VdJmSRQWVCnx9EF4pGeYjFZpDf7np8rdCyikApEqnizqkI9ms8ClL7Aa 9ch8NCSFkJEFEOe/cTj8+OKTesLrJRTzZiEHI1EXl6vEeiYNS9RVCyYUNeU7EZ2JkDJ7bz4R RaJcgjFeOyi0zi7eXbU7veOrzslJLbeC0iKLddFZOCxmp1uOu3RyHdM8xoS0/5yXdRYnzyrn jcVFPLZoW81TA80eNtAKzBI2Xgx4rbxHhG+QILdCLzdO+7G28R5kGnOxhkmJfhO4Msho/lUT rrKgB/dYEEsNzR82dlfac9lxCSxX5tuEz1n/VkUqZqedne0HNCTnDWW8aw2jqeM8lIfR931c GvUeq1aLS0zc6eFCwDUxTMK/4vymKuO7to8tTsNJlnhzoVIo2zbLhYP/pHV6DFtMdoCLBOXR DI1ZCNQKxNUvU2k3B1iUBx44FuY1ZqS2kG9RexHQBnLvefVTXfez9KdYZTArLMQ8+qG2njr9 FKGoaUgOLNnDombGtaRJc5eo2Fa5hBk8f668x4swdcQszKwKTMpKkI8d20WDFZkdy60ViYKp 4K3JgitQkra4iX73gwFvdbd+jXXRmxX+TY+T/cqJDNBr4Wc5Act1wdXe6LuW9zk0QUQ25XKe p9/0ParY1eyxKbg31lTZ9b1wJ0i3lbFjnICL+qlOYXGu5VxSqeUdReJ1aIPmgItscnsDwHo+ 1/GHt1nLdwSLHbQt0SKhM3RE0STvfFy/PTQcy68HJfV/rLYWKh3W9r2LiWXz+UvAB4Pbh0DG BV7ZQhiJQKgToFvtUGVzCsFrouMiUtHhE+0anCoxnKJv4FbH869NGPr6SIY2P/osiBixi368 d3LmNBfMW1/4/VgPbSUu4pC73/yrvXbH0Rk/LAkk3uOngZQGaS4jYBTlk1yTT7coek2VKlQH ZwYVYgmpdm2hUE/iqfM58ZdyNK4BuNumgGR4aA9r8Cty+vz1V8hGeiaPcGgnKZBoVQZU6sbT XFC02/6YTjFDTbyViHgAm882744jIjrMGE+KmtQsnHebhRKNqCS57kFS6vzaCeQwXm8PwIp8 t5inegzTC96gfTd2x97g+zFbqSwZmj2Xxp8iR2SGH7PG+lTOcMo+yO6jeEZJBGyROn5/c8D6 4FcMslKm4L1/Iv2kK8b0TOLMqig6AFl/1PCM4AtC3xrpJ29EYvniiiE+UalBEQGIG0gZ8gk6 H5MLPie3IqwjahuDuIzIxGkmREv1zFQx1HWCWA73ozXcH8GMoXIkHee/CPD8AuexcF8c3POT 4fA8Y4/HQf7oZ0K+95+b4WObfid2Pf9npeVvzZNKwwz41JdHs8lIlShbfwj0ej812/bO/3+g t4LhTwFeNmM9GnZLmaS6xV8fBrnzHwS5u5Ndep9xl+VxZUzv8L95jrv7B33q9XYeiS0+hoy3 21Th07UOqusHVmSpmxbqOMa4Ux0uP1xKziViwy47Vopr/VZIcwV0DQdNN9KH1Tgjz8z3MOK3 HX/XgZhxcNmhFzKxRCV4epB7imYrpsccONvBIXwQoUn3XTwY+CCjshE/a+6c0/NmAuockJbn Lj0/q7U4+71jYqk0qrR1LnJGNL+B0Z3Eqc+mM8qcf0WZTER8oyrZEXnzZjVJ/HyPHqsiMRMU dISYXsL4cXfMVt//g72Xr/bj+38vXu3v0/2/vb3K+v7fz2jr+3/r+3//6/f/nknHo9sZ9Lbq 4rh9RDfU8Ded0mW60ptpb+hKlF8eHea7XNlf7MMiYpjvm3qIgcEC3TzccWwvcql74QJcfxry 7biEeCbsyA+yw6WPEwlrjGOxmBSBB4VmAbCkyHPC5YA43errjoxN2yUTDXwRxje44uuKhICk mMtdWiSLqXHJRbovBkeXTee16m0v0LvWMAZ5/PIm8yqjrKmo6Aqh1708NsnR4dS2RRgi+l2i wKn0aejXXiPV06lpseNph5KiY6xe5IJl21g16wrH0AkKe6OppdiDuow4DZKbETw91253KjZc 67FEnGHAZ5Q+p3PhkCGf4cQntHl23+UAWdVwamYs7pTOfOKtjofVu5H4iLiM3wL/Okw0Fze2 UNdNm8edadRxlATS0RUhwsPThuJYZ6baoUojftZQD0hwRDYnY3pTRKnrj4oJIb0C4TcgNkLT pBcBBCYeumlu8n/+iN+YSaXHxEd9KcurcFf3aRJcglaJQexMPZv14BVCihyDcsycT6+XM+er O8mbkhRzD3hfVk/RkDrlBNOksLAGj0ton/RDB1ueLZQyfL8ymCIIA6WXuGErajtnq2m6fzvy 3UE+VKVHF20YZzyeUnNc6CXaqCnil9YcH1/uHDfr6jVPy0Vieukn2VbUsz35s4I8n/Ok1Pwa l/z2T3OJ5hNBqRnHv0EqMyvWYU5IvsxLQxY6IVe015dyTYU8zAiccMx1QaZ45t0ifdwjJln6 MGt2zTLfk/Uy7hbp1oy6yAfGv7v6W7d1W7d1W7d1W7d1W7d1W7d1W7d1W7d1W7d1W7d1W7d1 W7d1W7d1W7f/pfYvBG8S6wBQAAA= --C7zPtVaVf+AK4Oqc-- From owner-arts@space.twc.de Thu Sep 23 12:14:45 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA22553 for arts-list; Thu, 23 Sep 1999 12:14:00 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id MAA22548; Thu, 23 Sep 1999 12:13:58 +0200 Message-ID: <19990923121358.55174@space.twc.de> Date: Thu, 23 Sep 1999 12:13:58 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: A few more arts questions References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Andy Mucho on Tue, Sep 21, 1999 at 03:50:12PM +0100 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 650 Lines: 19 Hi! On Tue, Sep 21, 1999 at 03:50:12PM +0100, Andy Mucho wrote: > > A filter with adjustable Q (up to self oscillation) would be good news. > > Can't build a synth without. > > Try this. It's a really nice 4pole. Very Moog like. > > double MoogVCF::run(double input, double fc, double res) > [...] Is the code under a reasonable license so I could include it in the aRts distribution? Then I'll make a module out of it. I've been looking for something like that quite some time ;). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Thu Sep 23 13:28:19 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id NAA22756 for arts-list; Thu, 23 Sep 1999 13:28:12 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from netscanuk.com (root@netscanuk.com [209.176.31.30]) by space.twc.de (8.8.7/8.8.7) with ESMTP id NAA22753 for ; Thu, 23 Sep 1999 13:28:10 +0200 Received: from mother.software-superstars.com (localhost) by netscanuk.com (8.8.5) id MAA25620; Thu, 23 Sep 1999 12:27:23 -0400 (EDT) Received: from 192.168.1.2 ([192.168.1.2]) by mother.software-superstars.com (WinRoute Pro 4.0) with SMTP; Thu, 23 Sep 1999 12:28:55 +0100 From: "Andy Mucho" To: Subject: RE: A few more arts questions Date: Thu, 23 Sep 1999 12:27:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <19990923121358.55174@space.twc.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 814 Lines: 22 > -----Original Message----- > From: owner-arts@space.twc.de [mailto:owner-arts@space.twc.de]On Behalf > > double MoogVCF::run(double input, double fc, double res) > > Is the code under a reasonable license so I could include it in the > aRts distribution? Then I'll make a module out of it. I've been looking > for something like that quite some time ;). It turned up in the comp.dsp newsgroup during some discussions about IIR & FIR filters, and was bandied about quite freely as a solution to some guys problems, so I don't think there'll be any problems. The original author is contactable here: Timo Tossavainen [tt@cs.uta.fi] It does sound very good. Though make sure you keep everything as doubles, and watch out for denormaled numbers if you take the input away or let it drop to zero. Regards AndyM From owner-arts@space.twc.de Fri Sep 24 20:19:52 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA28910 for arts-list; Fri, 24 Sep 1999 20:19:33 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by space.twc.de (8.8.7/8.8.7) with SMTP id UAA28907 for ; Fri, 24 Sep 1999 20:19:30 +0200 Received: (qmail 25639 invoked by uid 0); 24 Sep 1999 18:21:03 -0000 Received: from host-62.96.49.116.inetservice.de (HELO gate.way) (62.96.49.116) by mail2.gmx.net with SMTP; 24 Sep 1999 18:21:03 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id UAA15510 for arts@space.twc.de; Fri, 24 Sep 1999 20:21:53 +0200 Date: Fri, 24 Sep 1999 20:21:53 +0200 From: Emmeran Seehuber To: Arts Mailing List Subject: Rectangle Wave & Instruments Message-ID: <19990924202153.A15457@gate> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=RnlQjJ0d97Da+TV1 X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 4889 Lines: 93 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Hi ! at the moment i'm trying to get a little deeper into arts. So i falled over the synthizeser modules. It seemed to be realy easy to make new modules - And so i tried it. :) And it was realy simple! ;) Appended you find a patch wich adds a rectangle wave synth to arts. I did also some instruments, wich uses this rectangle. Primary i wanted to make a organ; I'm not realy sure, that i reached this goal, but i don't know what's missing. Any idea ? cu, Emmy P.S.: Perhaps this can make it's way into arts-0.3.4 ? If so, you should give the instruments a better name. -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== --RnlQjJ0d97Da+TV1 Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="synth_wave_rect.tgz" Content-Transfer-Encoding: base64 H4sIAOG/6zcAA+1d6XPbuBXPV/uvwKRfbCeRCfCW63a8jtxq1kfqI20nk9FwJdrmRKa0JOWt m8n/XhAgJYAPIrhdr51kgXFsicb1Drzjh2clSfMiW9zFaTG6XkynoyweF70oK/IXj9ewZXmO g14ghHyP/8TV+7J5vkvK7z7xbZe+KX/r2e4LZD3iHta2RV5EGUIv4ru7h/Z+cfaYTPlKWhrd xfuJQgk272aTxTTeH6ZFnF1H43h0Mnw7HJ2eXQ42P28ilEz2LfrjP+z7A/s+n2XF/nUW/7yI 0/EDfVD2Yz0xezGepSmdeVTM9l364Es95D6ezsZJIY0gYod5Fud5PBF/bzdnDNiAL/W2Lx7S 4nZ0dD74x9Xg9PDf9ZYdtmXMtkxat+w2F8DSjma52Nlrdia2ajuD0/eD47N3g9HB24vzeks+ 25LNthTW80fjIrmPxSWC5hK2uJ8kvY+mC2lA2BwQ+uKIqCii8SdJSBZ7FS0myWw0iYpo3+pZ tmVZ4rBJPI5k0WI4ih54eVRenrIklcYROM5rjsviaRzlElnYhuPs5rjZogD8wA6QKGARkWmd pfIMUCd8lZgvLs+vDi9HPw6Pj2shY49J2WdSxmRFXzSRuemDJVzVEj9cXYyu3h0PT39crhAI qr1aYRpfF9ICgGbGlxXHk5tbaQCx2gf8tMhLGyINAcedKIn458H7weh8cHhZ00CIQIOz5qwR cPQ9negJEL0NLRIQrgMpx1hFx8HbtzUFNreJHqPAazmdcANEYms0mSSSHGwCLB7W0W0DVjlK hRUJqNTI0VMANMkJWymA/JRJVlHgADZhS2laBRIcftawpSXBAafNtttJAFY4CLUkAD7ZoYqC k6ultXAdQYtICwFQaWWWXkefilkmjfCa5pP0rC7m0wW88gFhnlI0AmEeEUXTRpkHVNf12ynz nCZl2OtGmge4GKjt+t8Hx9RiHV5dnh0dLd13IMjKaaEIsqtBkSoKCYBPLn1kN7ICcHZs0pms QDpEbXQFQDE8V09XANSwO13Q8CiDPyVdYRUBch8TttAVQm+PbS1hIThfQWfCQsBJnaHAVnWg XEaO30IOt5sy2yQHAk8UtsCRUsR2yljLUjBPqXyC3cbYEolpkw3Gv9Z9Ygz8J99kOx0YMC2s Q5kyZRoXiywuRzMaWC5F4yFGBXegbJ80gEmKZJayJKl4mK+WmCRlqlX+iq4+XxT8IWV02Wuf rpCkN8sNsGfzbDaPM5YrlTsv+4obJtAh1CGLOv8TUr80/mWW3UTpY6f/mvyf8phYzfzftbDJ /5+iNfP/Wgk6pP8+N6Vd8n8fqCX0hlTo4JELe8GBxJXMsgpN8KUUQQEn+MD0BkpzBQAFX0y7 nHYmgJ37kgFq5DkBCJdDZVSiBBWY769RBbzclwJWAGbRl6ISlcMHNpHYcuQPoIVA4Uj00ELg dnA/CmghAD64G7RQRTK/HloIQFoQQr8h+acmtABjmlCZaiqghZB7zQpa8Ff0NaCFELjMQBle QGghFNPy1QpNaAHSHAQSx5vQQgjScnmAAlpQBGXqbApgC6EnELFMChtnDkZggT5qA8InRBu3 Odx28kinLQ9SWEXZaijCNgfoP+4WgGKYEOPA68Re7GKBonX8xS6MwgJfuy1XYXEsHYtdbplD PYuhl9Gy2AN5WdCRxR5ENEKlq4EsZnlVTdFaFnsAjMahrd8WkDyxOkre55LHdvu+fCj6UAue YB+KvsIfW0RfO2VbL3udU1bIHubkHSEUDDNyHHa7t8CBKxyv9jgDB1ADHOmQNUUDU3h+UDvs K8SCTmr2FUIN8NpuVTD0KFy7u+zLF1VAtzFgwnHQvjFFXKpLb4kl2ny8DJgVWklg+kxsaUMg v+WntcErrWUlFjz2WIevEkwEmVcZ7hpCYP7Ml2whRHFP42vtF4F3M8TXEkLE4L0Nb+AeXY7P gnYybHh74OrJUFwLWMq7E8HcEdsTdZ39WEuIDQXuaIBVYgOwzuqRLgaPwDuCQCkUJVRHqiCp pqtV0WCYRHw9DElgqOR2husIjJY4e1uF5VbBNI/X23wTgWGPzjcRFyRaTkdiFFcJnjLGAraW sPhpSVK7rSUevAVy29JgAgMmonYC8DqxCpiqja2LTAiMmIinvVsjiojJV0YmosXxJem3mhxV 5CMxCtocH5hO0sEHQHCGn6buICfn7JOBnBialSUq+9x42rfWROhv9ilJJ4+O/mrxX8snoP4L u5bBf5+iAfyXKYEp/mrGbi0eSl381ci/lJ7heevBGsmXKQgzBWGmIOz/KQiTH6nBX1MjZmrE TI2YqREzNWK/oUbMf9oasQqpbcOdvoYiMawFnUyZ2POVia0lowafqwCtDbXFEH7W0aGAn22t G8Iw4lhzESQqVw0/ux0IgfBzqDHZWIU+u520C0YfWH1tzOLOy/Ph6nre3lzFncvj0rwFckAU qQ08lUVOuj8qwK4lqUqbQeKzKQqrWnRFcSlva+NGxaU8v0jvcinfofxWVfslX6B0upbvqisQ Za5p+T7qPNc1AfphdX/k6fE/qmxeE/+zXM/gf0/RmvgfVwJT/WmqP9eF8qb601R/murP5RhT /bmMOk31p5YWU/1pqj9N9aep/jTVn2sIMdWfpvqTjzbVn835TfWnqf401Z+m+vMxmwD9/R4f /cea5vP/fI/gGv/1fZu+xrZnEYP/PkVr4r/mo/++x4/+a9znmVJPU+ppSj1Nqacp9TSlnk2L ako9TannV1Dq+cQfB2hKPU2p5x+91FN7bf1NFnp+3+V7v7kJqX+e3M2n8e8AA2nwH+J5dqP+ z8We+fzHJ2lN/EdQgm8NBlJ/OPuz4UDqGhUlDlS5uUYJBQSCoI/TIUHQx2mRIAXG0gEJ6hIX qJAgRZFfJyRIUeTX6VISgiwEsIhIXAVIEKz4UkpahQTxqzLuP4MVeQ0gSAG7KCNaCAQRvKm4 0m7iQJBiLPlmiAPBsyYNUOFA8DKqIw4UbupxIBjyaHEgxZ+21OFnpxAhePYIob5efFT7z4WR 98bj3jwqxrePOnnVdP4fe37t/6n79+hvieuY///pSdrOzg4qg703Vs/u2bt5Nt7Ny4MZ58l/ 42x3pR4bl7cLdLC4oeEawl7f9vsWRjgMw803b96gXm+32yxHWYIu4jkiDiJW37L6JOSz7Mit fI+w7fqv6bcQsUflQtWj0EX03Rt6IujXxvUs20r2rb3kz+OHMV1oL3n1ahvRk5gnNx+Sj2gf 0dOVbtEwh73foS/G0TSmL7d3cc/18R47Wq8Q/RpPozxHDeOE+vPFT9NkzJ+fMHJo38/038bu Lj2keYGStEDD0/cHx1cDupUN+hwdDf91Mmj2WQYktBdfsuyapNRq5P3yXZwu7tBn9O7sYng5 PDtFX4Ru3LpI/c6uLtmivN/GnybxdZLG6OLgpHQNfzs/uBwgx6FnsJplOktvSktW9uZUsdnu Z8kEDVNq36IpFdrWNp2a9qK8s/bQbXQfH0bT8WIaFfEPNFb7RJ9Tqxnv8UXZ4GWHrW3FQzZq a1GKII0niO0ij8pgM+fduZFEN3HxLsqiu5ztIIupXU63Xpb7ra36y+09Jiw6IiqoTNg6O4fU jdKMUhiF0viXpiD5yJqjXJCH04RGvujkcNTovCVIu9+nGxudXLx+2ej08nXjQb9fbWW7WoXt D3ZacavWJKp41CNsXUfTPGaDv3SaoI2z9dTX01lUoJ2ahVR69OWHWnU+vkY7XNZJ+qHWu4+1 2skzJ0xYqxNXrbQ8cmx+fujolOWLv1AV6rnorwijPrI4Xc9t9kwzzTTTTDPtD93+B1UThNsA eAAA --RnlQjJ0d97Da+TV1-- From owner-arts@space.twc.de Tue Sep 28 23:33:27 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA07527 for arts-list; Tue, 28 Sep 1999 23:32:45 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id XAA07522; Tue, 28 Sep 1999 23:32:44 +0200 Message-ID: <19990928233243.31386@space.twc.de> Date: Tue, 28 Sep 1999 23:32:43 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Rectangle Wave & Instruments References: <19990924202153.A15457@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19990924202153.A15457@gate>; from Emmeran Seehuber on Fri, Sep 24, 1999 at 08:21:53PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1259 Lines: 40 Hi! On Fri, Sep 24, 1999 at 08:21:53PM +0200, Emmeran Seehuber wrote: > at the moment i'm trying to get a little > deeper into arts. So i falled over the > synthizeser modules. It seemed to be realy > easy to make new modules - And so i tried > it. :) > > And it was realy simple! ;) > > Appended you find a patch wich adds a rectangle > wave synth to arts. I did also some instruments, > wich uses this rectangle. Well - Jens Hahn was faster with that than you. (His implementation is called Synth_WAVE_SQUARE though). > Primary i wanted to make a organ; I'm not realy > sure, that i reached this goal, but i don't know > what's missing. Any idea ? > > cu, > Emmy > > P.S.: Perhaps this can make it's way into arts-0.3.4 ? > If so, you should give the instruments a better name. Yes - it will go into arts-0.3.4 - I changed RECT -> SQUARE. Well, but I wasn't creative on names - these are just like you sent me the files. Probably some day someone should start maintaing instruments, samples, structures, mixer elements, effects etc. and start categorizing them in a useful way. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Wed Sep 29 23:19:24 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA11795 for arts-list; Wed, 29 Sep 1999 23:15:20 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id XAA11790; Wed, 29 Sep 1999 23:15:18 +0200 Message-ID: <19990929231518.61378@space.twc.de> Date: Wed, 29 Sep 1999 23:15:18 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: aRts-0.3.4 released. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1963 Lines: 55 Hi! Well - there is it, the new aRts version. Finally, some big wishes come true. Sequencer integration with Brahms, which you really need to do serious composing, full duplex support and the resonant cutoff filter posted to the list recently as module. And more. Detailed list of changes since aRts-0.3.3: - Brahms (a really nice sequencer KDE application, formerly called kooBase) and aRts interoperate now nicely. - full duplex support, that means you can use it for full duplex effect processing now (real low latency)! - audio subsystem features configurable fragment size now, so people who want to use aRts "just" as audio server, and insist in running without root rights have a chance now - put suid functionality in a seperate small C program for security reasons (this should be easier to overview) - implemented recording interface for the audioserver, so an equivalent to the esdmon and esdrec functionality is now available - mapped instruments now available, so one midi instrument may now contain a drum map with different samples - Akai support: added utilities to read Akai Sample CDs & build keymaps from akai samples and play them in instruments with Synth_PLAY_AKAI - Session management: while you are in a performace, you can save all settings, such as instrument setup, mixer parameters, instrument parameters, and restore them later - added Synth_MOOG_VCF, a nice 4pole lowpass with resonance (thanks Andy Mucho for the hint) - mico-2.3.0 support - bugfixes - new version of midisend, which allows keyboard splitting and similar mapping operations (Emmeran Seehuber) - new icons for many modules (Harald Lapp) - new modules: Synth_SQUARE, Synth_FX_CFLANGER, Synth_AUTOPANNER (Jens Hahn) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Oct 1 12:10:09 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA17217 for arts-list; Fri, 1 Oct 1999 12:09:41 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id MAA17212; Fri, 1 Oct 1999 12:09:39 +0200 Message-ID: <19991001120939.47872@space.twc.de> Date: Fri, 1 Oct 1999 12:09:39 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Problems with Brahms-0.97.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 520 Lines: 14 Hi! I've got a report that compiling Brahms-0.97.1 with installed aRts-0.3.4 fails with certain mico versions. In the player subdirectory, midibus.h can't be read. Removing midibus.h/midibus.cc in the player subdirectory should fix that problem (they are autogenerated by mico, and things will only work if you generate them with the same mico version). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Oct 1 13:52:05 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id NAA17654 for arts-list; Fri, 1 Oct 1999 13:51:57 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id NAA17651 for ; Fri, 1 Oct 1999 13:51:56 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id NAA25837 for ; Fri, 1 Oct 1999 13:53:44 +0200 (MET DST) Date: Fri, 1 Oct 1999 13:53:44 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: Problems with Brahms-0.97.1 In-Reply-To: <19991001120939.47872@space.twc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 735 Lines: 22 On Fri, 1 Oct 1999, Stefan Westerfeld wrote: Hi, I downloaded the new stuff yesterday and I figure you're approaching the point where we can actually make music with arts. Two quick questions before the first sessions on the weekend: Is it possible to use the semistatic arts distribution and compile Brahms or do I need the arts source tree to get the arts - Brahms connection? > I get (with the newest semistatic) not more than two notes playing at the same time. Is this what I should expect from a 233 MhZ P MMX? BTW something seems to have changed in midisend, apparently it is hardwired to /dev/midi now, so I had to ln -s /dev/midi00 /dev/midi to get it to work. Thanks for the quick realisation of the Moog VCF, Reiner From owner-arts@space.twc.de Fri Oct 1 17:25:21 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id RAA18861 for arts-list; Fri, 1 Oct 1999 17:25:12 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id RAA18856; Fri, 1 Oct 1999 17:25:11 +0200 Message-ID: <19991001172511.15164@space.twc.de> Date: Fri, 1 Oct 1999 17:25:11 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with Brahms-0.97.1 References: <19991001120939.47872@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Reiner Klenk on Fri, Oct 01, 1999 at 01:53:44PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2171 Lines: 49 Hi! On Fri, Oct 01, 1999 at 01:53:44PM +0200, Reiner Klenk wrote: > I downloaded the new stuff yesterday and I figure you're approaching the > point where we can actually make music with arts. Two quick questions > before the first sessions on the weekend: > > Is it possible to use the semistatic arts distribution and compile Brahms > or do I need the arts source tree to get the arts - Brahms connection? > I'd recommend compiling aRts from source as this is tested to work out-of- the-box. You can also copy arts.idl and midibus.idl in the idl directory inside the kde include directory manually (from the arts-0.3.4 sources) and then go ahead with semistatic binary. > I get (with the newest semistatic) not more than two notes playing at > the same time. Is this what I should expect from a 233 MhZ P MMX? Well - I get about 7 nice voices (not nice voices are faster ;) and two equalizer channels and the delay effect running on a PII-350. You can try playing with the realtime settings (artsshell -s -i to see the parameters, and artsshell -S / -F / -R to modify). And of course performance depends on what actually gets executed. An instrument with one oscillator and a filter is likely to take less CPU usage than an instrument with four oscillators and four filters. Mixers/Equalizers also take CPU time. Anyway - aRts is slow - I don't know how much it can be optimized, and how much is really unavoidable for such a modularity. Rewriting the scheduling might make executions faster by a factor of about 1.5 from my calculations. (I'll do that some day). If you like - try profiling and optimizing stuff yourself. Another hint might be to use -O6 -mpentiumpro or -O6 -mpentium or whatever for optimizations. > BTW something seems to have changed in midisend, apparently it is > hardwired to /dev/midi now, so I had to ln -s /dev/midi00 /dev/midi to > get it to work. Yes, it has been partially rewritten and supports keyboard splitting and things like that now (see documentation). ;) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Oct 1 20:36:41 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA19822 for arts-list; Fri, 1 Oct 1999 20:35:14 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id UAA19819 for ; Fri, 1 Oct 1999 20:35:12 +0200 Received: (qmail 9164 invoked by uid 0); 1 Oct 1999 18:37:02 -0000 Received: from ppp23210.01019freenet.de (HELO gate.way) (212.81.218.170) by mail1.gmx.net with SMTP; 1 Oct 1999 18:37:02 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id UAA04518 for arts@space.twc.de; Fri, 1 Oct 1999 20:36:14 +0200 Date: Fri, 1 Oct 1999 20:36:14 +0200 From: Emmeran Seehuber To: Arts Mailing List Subject: Problems with actual aRTs Message-ID: <19991001203614.A4468@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1205 Lines: 36 Hi ! i've got some problems with the actual aRTs. (Version from cvs today) I'm starting arts and load the example_isntrument_pure. Than i execute it. On an other terminal i start midisend. Now i add a instrument with channel 0. Than i play a little on the keyboard. First it sound's as usal. But then arts begins to plays notes, i've never pressed. It happens when i press four keys or more. And than arts begins to make noise (sometimes with a high tune and sometimes with a low tune). It only stops, when i remove the instrument. I've started midisend with "-v"; The notes that come in are all correct. I get this message 4 time's when i start the example_instrument_pure: FULL DUPLEX WARNING: client->needMore() failed; no more data available Perhaps this has something to do with the problem. I had this problem already sometimes with ealier versions of arts. But it did not often occur. Now it gets a realy serios problem and makes arts unusable for me. What's going on ? Any idea ? cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Fri Oct 1 22:23:59 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id WAA20518 for arts-list; Fri, 1 Oct 1999 22:22:36 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id WAA20513; Fri, 1 Oct 1999 22:22:34 +0200 Message-ID: <19991001222234.07058@space.twc.de> Date: Fri, 1 Oct 1999 22:22:34 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with actual aRTs References: <19991001203614.A4468@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19991001203614.A4468@gate>; from Emmeran Seehuber on Fri, Oct 01, 1999 at 08:36:14PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2989 Lines: 74 Hi! On Fri, Oct 01, 1999 at 08:36:14PM +0200, Emmeran Seehuber wrote: > i've got some problems with the actual aRTs. (Version > from cvs today) Well - in any case there is no warranty on any cvs version, if you use them, you are on your own risk. Sometimes I also commit bugs (like today the not-quite-perfect QT2 support, which is fixed now tough) or even routines which are known buggy. The releases are somewhat tested. Anyway - that shouldn't have caused your problem right now... > I'm starting arts and load the example_isntrument_pure. Than > i execute it. On an other terminal i start midisend. Now i add > a instrument with channel 0. > > Than i play a little on the keyboard. First it sound's as usal. But > then arts begins to plays notes, i've never pressed. It happens when > i press four keys or more. And than arts begins to make noise (sometimes > with a high tune and sometimes with a low tune). It only stops, when i remove > the instrument. > > I've started midisend with "-v"; The notes that come in are all correct. > > I get this message 4 time's when i start the example_instrument_pure: > FULL DUPLEX WARNING: client->needMore() failed; no more data available > > Perhaps this has something to do with the problem. > > I had this problem already sometimes with ealier versions of arts. But > it did not often occur. Now it gets a realy serios problem and > makes arts unusable for me. > > What's going on ? Perhaps it's related to your buggy midi keyboard? (You told something about that earlier)? Please first of all doublecheck that the events are allright. For instance you could try capturing midisend -v output to a file, and use grep and wc to see that NoteOns and NoteOffs are really balances. > Any idea ? Well, I can't reproduce the problem here. The only thing which I was able to get was some real noise, if you turn the number of voices to a very high value, and then play too many notes. Well, thats CPU overload, nothing more. Perhaps one thing about that: the voices that are in the release phase also consume CPU time, so even if you only hold down four or five keys at a time, you can easily consume 10 voices or more, when playing fast and using long release times. You could try to debug what midi events the synthesis server really processes, by adding one additional Synth_MIDI_DEBUG thing to the structure (the example_instrument_pure structure, not the instrument itself). Does the problem happen with all instruments? Is your CPU load near to the limit of 90%? Has the number of active modules (use artsshell -i) increased, after you have pressed notes, released and then there is noise - as you say - that only disappears when removing the instrument? Can you capture the wrong output to a wave file using a Synth_FILEPLAY parallel to the Synth_PLAY? Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Fri Oct 1 23:10:50 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id XAA20729 for arts-list; Fri, 1 Oct 1999 23:09:34 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by space.twc.de (8.8.7/8.8.7) with SMTP id XAA20726 for ; Fri, 1 Oct 1999 23:09:33 +0200 Received: (qmail 25998 invoked by uid 0); 1 Oct 1999 21:11:22 -0000 Received: from host-62.96.50.88.inetservice.de (HELO gate.way) (62.96.50.88) by mail1.gmx.net with SMTP; 1 Oct 1999 21:11:22 -0000 Received: (from emmy@localhost) by gate.way (8.9.3/8.9.3) id XAA08258 for arts@space.twc.de; Fri, 1 Oct 1999 23:07:06 +0200 Date: Fri, 1 Oct 1999 23:07:06 +0200 From: Emmeran Seehuber To: arts@space.twc.de Subject: Re: Problems with actual aRTs Message-ID: <19991001230706.A8057@gate> References: <19991001203614.A4468@gate> <19991001222234.07058@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <19991001222234.07058@space.twc.de> Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1393 Lines: 42 On Fri, Oct 01, 1999 at 10:22:34PM +0200, Stefan Westerfeld wrote: > > What's going on ? > > Perhaps it's related to your buggy midi keyboard? (You told something > about that earlier)? Please first of all doublecheck that the events > are allright. For instance you could try capturing midisend -v output > to a file, and use grep and wc to see that NoteOns and NoteOffs are > really balances. They really balances. > > > Any idea ? > > > You could try to debug what midi events the synthesis server really > processes, by adding one additional Synth_MIDI_DEBUG thing to the > structure (the example_instrument_pure structure, not the instrument > itself). > > Does the problem happen with all instruments? Yes. > > Is your CPU load near to the limit of 90%? No. Far away from this. > Has the number of active modules (use artsshell -i) increased, after you > have pressed notes, released and then there is noise - as you say - that > only disappears when removing the instrument? > > Can you capture the wrong output to a wave file using a Synth_FILEPLAY > parallel to the Synth_PLAY? Yes. Did it - I'll send the wav directly to your mail. (Of course in compressed form :-) cu, Emmy -- ============================================================== EMail Private: the_emmy@gmx.de Work: e.seehuber@mylius.com ============================================================== From owner-arts@space.twc.de Sat Oct 2 16:48:24 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id QAA23302 for arts-list; Sat, 2 Oct 1999 16:47:52 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id QAA23297; Sat, 2 Oct 1999 16:47:50 +0200 Message-ID: <19991002164750.52388@space.twc.de> Date: Sat, 2 Oct 1999 16:47:50 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with actual aRTs References: <19991001203614.A4468@gate> <19991001222234.07058@space.twc.de> <19991001230706.A8057@gate> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <19991001230706.A8057@gate>; from Emmeran Seehuber on Fri, Oct 01, 1999 at 11:07:06PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 465 Lines: 13 Hi! On Fri, Oct 01, 1999 at 11:07:06PM +0200, Emmeran Seehuber wrote: > Yes. Did it - I'll send the wav directly to your mail. > (Of course in compressed form :-) We tracked down the problem now - the midi events are really wrong, and aRts is working perfect. So don't be afraid of the new aRts ;) Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Sun Oct 3 12:26:09 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id MAA26079 for arts-list; Sun, 3 Oct 1999 12:25:55 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id MAA26076 for ; Sun, 3 Oct 1999 12:25:53 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id MAA13403 for ; Sun, 3 Oct 1999 12:27:45 +0200 (MET DST) Date: Sun, 3 Oct 1999 12:27:45 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: Problems with Brahms-0.97.1 In-Reply-To: <19991001172511.15164@space.twc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2412 Lines: 55 > > I'd recommend compiling aRts from source as this is tested to work out-of- > the-box. You can also copy arts.idl and midibus.idl in the idl directory > inside the kde include directory manually (from the arts-0.3.4 sources) > and then go ahead with semistatic binary. My problem is that the binaries that I compile myself are segfaulting. Artsserver seems to be fine but the builder crashes just after displaying "AR-UP". I suspect a problem with my kdelibs (1.1), stracing reveals that artsbuilder dies just after accessing a Kdebug.areas file. I'll try upgrading my KDE packages and see if this helps. Meanwhile I've succeded in playing a few notes from Brahms to arts (semistatic) via midibus, in principle it seems to work but Brahms is quite unstable. I'll stick to my external midi sequencer for now. > You can try playing with the realtime settings (artsshell -s -i to see > the parameters, and artsshell -S / -F / -R to modify). Thanks for the tip. > > Another hint might be to use -O6 -mpentiumpro or -O6 -mpentium or whatever > for optimizations. Yes, I want to try that when I get my own compiling to work. I'll also try compiling it with pgcc which I have installed for the jmax package. A few other points on my wishlist (which you may silently ignore, but maybe you're interested in some user feedback) 1) switches. For example to have 3 oscillators (sine, square, saw) connected to a switch whose output is connected to the rest of the structure. I'm using the cross-fader for this but some resources could be saved if the audio engine detects that two of the three VCOs are not connected and don't have to be calculated. A string port could be used to set the switch position. 2) control-signals. Everything is done with audio channels now but in many cases we don't need the sampling rate. Control signals could be processed at a much lower rate. To keep things flexible one would need audio-control and control-audio converter modules. 3) adjustable duty cycles. It would be nice if the square and saw had an adjustable duty cycle which could be modulated by LFO, ADSR etc. 4) midi controller ports. For real-time remote control. 5) snapshots. A possibility to store and reload the settings of all gui elements in a panel. 6) glide (portamento). This may be tricky due to the concept of arts, i.e. creating and destroying the structure for each single note. Regards, Reiner From owner-arts@space.twc.de Sun Oct 3 16:30:29 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id QAA26534 for arts-list; Sun, 3 Oct 1999 16:30:26 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id QAA26529 for arts; Sun, 3 Oct 1999 16:30:25 +0200 From: Stefan Westerfeld Message-Id: <199910031430.QAA26529@space.twc.de> Subject: Mandrake6.0 & aRts-0.3.4 To: arts@space.twc.de Date: Sun, 3 Oct 1999 16:30:25 +0200 (CEST) Content-Type: text Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 894 Lines: 28 Hi! Here's a fix for Mandrake 6.0 users. Cu... Stefan Forwarded message: > To compile this version of aRts on a Linux intel PC (Mandrake 6.0 > distribution, basically a RH 6.0) I had to add the line : > > #include > > At the begining of the file: > > arts-0.3.4/src/synthesizer/audiosubsys.cc > > > Before that the complain was : > > g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../common -I/usr/local/include > -I/usr/include -I/usr/lib/qt/include -I/usr/X11R6/include -O2 -Wall-c > audiosubsys.cc > audiosubsys.cc: In method `int AudioSubSystem::open(int, int, int, int, bool)': > audiosubsys.cc:86: `errno' undeclared (first use this function) > audiosubsys.cc:86: (Each undeclared identifier is reported only once > audiosubsys.cc:86: for each function it appears in.) audiosubsys.cc:98: > confused by earlier errors, bailing out make[3]: *** [audiosubsys.o] > Error 1 From owner-arts@space.twc.de Sun Oct 3 17:09:43 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id RAA26612 for arts-list; Sun, 3 Oct 1999 17:09:32 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id RAA26609 for ; Sun, 3 Oct 1999 17:09:31 +0200 Received: from rhein-main.netsurf.de (root@dialin36.rhein-main.netsurf.de [194.163.193.36]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA32124 for ; Sun, 3 Oct 1999 17:11:18 +0200 Message-ID: <37F78BBB.4481B2F0@rhein-main.netsurf.de> Date: Sun, 03 Oct 1999 19:00:43 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: Re: Mandrake6.0 & aRts-0.3.4 & SuSE6.2 References: <199910031430.QAA26529@space.twc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 586 Lines: 23 Stefan Westerfeld wrote: > > Hi! > > Here's a fix for Mandrake 6.0 users. > hi! this seems also be necessary for SuSE6.2. i've just upgradet from 6.0 this weekend. cu <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Sun Oct 3 17:40:37 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id RAA26647 for arts-list; Sun, 3 Oct 1999 17:40:35 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from server5.aranea.net (server5.aranea.net [194.163.193.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id RAA26644 for ; Sun, 3 Oct 1999 17:40:34 +0200 Received: from rhein-main.netsurf.de (root@dialin38.rhein-main.netsurf.de [194.163.193.38]) by server5.aranea.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA32525 for ; Sun, 3 Oct 1999 17:42:09 +0200 Message-ID: <37F792F9.D4B2E309@rhein-main.netsurf.de> Date: Sun, 03 Oct 1999 19:31:37 +0200 From: Harald Lapp Organization: aRts - analog realtime synthesizer X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: arts@space.twc.de Subject: SuSE6.2 & aRts-0.3.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 550 Lines: 17 hi again yes... it compiles with the fixed audiosubsys.cc but now i get a 'segmentation fault' when starting artsbuilder... any ideas? cu <-harald -- ____ __ __ ______ email: harald.lapp@rhein-main.netsurf.de / \/ | \| _ \ www : http://aurora.home.pages.de/ / /\ \ | \ | ) ) http://arts.linuxbox.com/ / /_ \ \ | ) |( ( -------------------------------------------(_____\-\__\____/__|-\__\----- From owner-arts@space.twc.de Mon Oct 4 01:09:27 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA27744 for arts-list; Mon, 4 Oct 1999 01:09:09 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id BAA27739; Mon, 4 Oct 1999 01:09:08 +0200 Message-ID: <19991004010908.45016@space.twc.de> Date: Mon, 4 Oct 1999 01:09:08 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: SuSE6.2 & aRts-0.3.4 References: <37F792F9.D4B2E309@rhein-main.netsurf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <37F792F9.D4B2E309@rhein-main.netsurf.de>; from Harald Lapp on Sun, Oct 03, 1999 at 07:31:37PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1359 Lines: 46 Hi! On Sun, Oct 03, 1999 at 07:31:37PM +0200, Harald Lapp wrote: > yes... it compiles with the fixed audiosubsys.cc > > but now i get a 'segmentation fault' when starting > artsbuilder... any ideas? Does it print something (and/or show the start artsserver messagebox thing), before segfaulting? Does artsserver print something? 1. You could try to start artsbuilder -ORBIIOPAddr inet:localhost:8889 One user (with a pretty strange network configuration) reported this as problem. 2. You could try to recompile without threading (see autorouter.h, change one define for that). 3. Try backtracing artsbuilder, that is: * compile artsbuilder with debugging enabled, that means - go to src/ksbuild - edit the Makefile, and look for -O2 (will be in CXXOPTS or something like that) - replace it with -g - be sure that LDFLAGS doesn't contain -s (which would mean stripping the debugging symbols again when linking) - make clean - make * install it * start it with gdb artsbuilder * run it (type run) * when it crashes, type bt (for backtrace) and send me the output I hope that will do it. (It should help to find out why and where arts- builder crashes). Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Oct 4 01:48:19 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id BAA27794 for arts-list; Mon, 4 Oct 1999 01:48:18 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id BAA27789; Mon, 4 Oct 1999 01:48:17 +0200 Message-ID: <19991004014817.06555@space.twc.de> Date: Mon, 4 Oct 1999 01:48:17 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Problems with Brahms-0.97.1 References: <19991001172511.15164@space.twc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Reiner Klenk on Sun, Oct 03, 1999 at 12:27:45PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 4808 Lines: 103 Hi! On Sun, Oct 03, 1999 at 12:27:45PM +0200, Reiner Klenk wrote: > > > > I'd recommend compiling aRts from source as this is tested to work out-of- > > the-box. You can also copy arts.idl and midibus.idl in the idl directory > > inside the kde include directory manually (from the arts-0.3.4 sources) > > and then go ahead with semistatic binary. > > My problem is that the binaries that I compile myself are segfaulting. > Artsserver seems to be fine but the builder crashes just after displaying > "AR-UP". I suspect a problem with my kdelibs (1.1), stracing reveals that > artsbuilder dies just after accessing a Kdebug.areas file. I'll try > upgrading my KDE packages and see if this helps. Have you got a libc5 system? It's likely that threading is broken then. > Meanwhile I've succeded > in playing a few notes from Brahms to arts (semistatic) via midibus, in > principle it seems to work but Brahms is quite unstable. I'll stick to my > external midi sequencer for now. Well - you are lucky if you have an external sequencer. I don't, so I'll have to make Brahms work perfectly ;). But anyway: I have been working seriously with Brahms for quite a few days now, and it's okay. You have to save a bit more often, and sometimes you really wonder why feature xxx which you need right now isn't there. But hey - I've composed the first real minute of music on linux I ever did compose on linux (well there were some more or less successful tries with Jazz and RoseGarden, but Brahms is a lot nicer than both, I think). So it's something real. > A few other points on my wishlist (which you may silently ignore, but > maybe you're interested in some user feedback) User feedback is always welcome. Open development starts where people contribute ideas. > 1) switches. For example to have 3 oscillators (sine, square, saw) > connected to a switch whose output is connected to the rest of the > structure. I'm using the cross-fader for this but some resources could be > saved if the audio engine detects that two of the three VCOs are not > connected and don't have to be calculated. A string port could be used to > set the switch position. Well - it requires rewriting the scheduler, which is on my TODO. > 2) control-signals. Everything is done with audio channels now but in many > cases we don't need the sampling rate. Control signals could be processed > at a much lower rate. To keep things flexible one would need audio-control > and control-audio converter modules. It is currently often done implicitely - for instance the equalizers and shelve cutoff filters only recalculate filter parameters every time they calculate a block of samples, not every sample. However explicit control- signals would probably make things a bit faster and a bit clearer. Requires rewriting the scheduler. > 3) adjustable duty cycles. It would be nice if the square and saw had an > adjustable duty cycle which could be modulated by LFO, ADSR etc. So, you'd like to have a - duty cycle square module, which returns -1 if pos < duty 1 if pos >= duty - duty cycle saw module, which returns -1 if pos < duty (2*x-d-1)/(1-d) if pos >= duty Should be easy to implement, now that I played with gnuplot for a few minutes. Any creative ideas for naming them (Synth_WAV_*)? They shouldn't be called like the normal modules for backward compatibility. > 4) midi controller ports. For real-time remote control. > > 6) glide (portamento). This may be tricky due to the concept of arts, i.e. > creating and destroying the structure for each single note. Controllers aren't that hard to implement, only will they probably kill the midibus, when used extensively. It's probably necessary to implement a new "signal transfer middleware" anyway, since scopes also won't work well with CORBA. Would implementing using a pitch bend controller, whose range for instance can be specified from the instrument mapper (which then will pass a parameter to the midirouter) be ok for portamento? I suppose its ugly to write songs who do portamento from one note to another with that, but on the other hand it seems to be like midi pitchbending works. > 5) snapshots. A possibility to store and reload the settings of all gui > elements in a panel. Is saving sessions not enough? Probably session management could be extended easily to save just-that-panel, but the problem is where exactly to save that information. Normally, the GUI server wouldn't know where that structure (from the panel) came from. It may have been autogenerated for instance by the instrument mapper, or from somewhere published, or whatever. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From owner-arts@space.twc.de Mon Oct 4 09:55:00 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id JAA28908 for arts-list; Mon, 4 Oct 1999 09:54:56 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id JAA28905 for ; Mon, 4 Oct 1999 09:54:54 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id JAA05454 for ; Mon, 4 Oct 1999 09:56:48 +0200 (MET DST) Date: Mon, 4 Oct 1999 09:56:48 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: Problems with Brahms-0.97.1 In-Reply-To: <19991004014817.06555@space.twc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 2761 Lines: 67 > Have you got a libc5 system? It's likely that threading is broken then. Nope, it's Halloween Linux which is based on RH6, so it's glibc. I've upgraded KDE to the "official" Redhat 1.1.2 package. Now arts reports an uncaught MICO error just after loading GUI_knob. The builder seems to be OK, it runs with the semistatic server. I'll have a look at the tips you gave in the previous mails concerning SUSE and segfaults. BTW I also had that problem with missing errno definition. > But hey - I've composed the first real minute of music on linux I ever did > compose on linux (well there were some more or less successful tries with > Jazz and RoseGarden, but Brahms is a lot nicer than both, I think). So it's > something real. I agree, it looks promising. > > > 3) adjustable duty cycles. It would be nice if the square and saw had an > > adjustable duty cycle which could be modulated by LFO, ADSR etc. > > So, you'd like to have a > > - duty cycle square module, which returns > -1 if pos < duty > 1 if pos >= duty > - duty cycle saw module, which returns > -1 if pos < duty > (2*x-d-1)/(1-d) if pos >= duty > > Should be easy to implement, now that I played with gnuplot for a few > minutes. Any creative ideas for naming them (Synth_WAV_*)? They shouldn't > be called like the normal modules for backward compatibility. I'm not sure. Square looks OK. But saw should always be ramp-up, ramp-down. It would change from a saw where the ramp-up lasts the whole period and the ramp-down time is zero over a triangle (ramp-up time = ramp-down time) to an inverted saw (ramp-up time = 0, ramp-down time = whole period). These we could call Synth_WAV_pulse or Synth_WAV_square_pwm and Synth_WAV_saw_pwm, respectively. The pwm stands for pulse width modulation. > > 6) glide (portamento). This may be tricky due to the concept of arts, i.e. > > creating and destroying the structure for each single note. > > Would implementing using a pitch bend controller, whose range for instance > can be specified from the instrument mapper (which then will pass a parameter > to the midirouter) be ok for portamento? I suppose its ugly to write songs > who do portamento from one note to another with that, but on the other hand > it seems to be like midi pitchbending works. A pitch bender is always nice to have. The problem may be to avoid re-triggering the ADSR. I think I'll try to find out how these things are implemented in reaktor, Cubase and my MC303 and give a summary here. > > > 5) snapshots. A possibility to store and reload the settings of all gui > > elements in a panel. > > Is saving sessions not enough? Oops, wasn't aware of this feature. I'll find out if it does what I want. Thanks, Reiner From owner-arts@space.twc.de Wed Oct 6 15:45:06 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA04097 for arts-list; Wed, 6 Oct 1999 15:44:26 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from motti.st.jyu.fi (root@motti.st.jyu.fi [130.234.40.26]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA04092 for ; Wed, 6 Oct 1999 15:44:23 +0200 Received: from lihamureke.olli.net (IDENT:root@dynamic56.dialup.jyu.fi [130.234.125.56]) by motti.st.jyu.fi (8.9.3/8.9.3/antispam3) with ESMTP id QAA05846 for ; Wed, 6 Oct 1999 16:46:20 +0300 Received: from localhost (dst@localhost) by lihamureke.olli.net (8.9.3/8.9.3) with ESMTP id OAA07389 for ; Wed, 6 Oct 1999 14:29:49 +0300 Date: Wed, 6 Oct 1999 14:29:49 +0300 (EEST) From: Olli Sulopuisto To: arts@space.twc.de Subject: aRts 0.3.4 compile fails with audiosubsys Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1257 Lines: 30 To be brief, aRts won't compile on my RH6-based system and I didn't find any references to this particular problem in the mail archives so I decided to post this. To get tot the point, here's what make left me with: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../common -I/usr/local/include -I/usr/include/kde -I/usr/include/qt -I/usr/X11R6/include -O2 -Wall -c audiosubsys.cc audiosubsys.cc: In method `int AudioSubSystem::open(int, int, int, int, bool)': audiosubsys.cc:86: `errno' undeclared (first use this function) audiosubsys.cc:86: (Each undeclared identifier is reported only once audiosubsys.cc:86: for each function it appears in.) audiosubsys.cc:98: confused by earlier errors, bailing out make[3]: *** [audiosubsys.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 The relevant (any more?) components and their versions are egcs 1.1.2, qt 1.44, audiofile 0.1.9, mico 2.3.0 and kde 1.1.2. I'm also using ALSA project's drivers, hope that hasn't anything to do with this? Any help will be greatly appreciated. -- Olli Sulopuisto, JYU TJT, GSM: 050-3554767, dst@iki.fi, http://www.iki.fi/dst/ i see liberals i am just a fashion accessory - manic street preachers From owner-arts@space.twc.de Wed Oct 6 15:54:50 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id PAA04129 for arts-list; Wed, 6 Oct 1999 15:54:49 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dsmail.hmi.de (dsmail.hmi.de [134.30.15.24]) by space.twc.de (8.8.7/8.8.7) with ESMTP id PAA04126 for ; Wed, 6 Oct 1999 15:54:48 +0200 Received: from daniel.hmi.de (daniel.hmi.de [134.30.15.2]) by dsmail.hmi.de (8.9.1a/8.9.1) with ESMTP id PAA10051 for ; Wed, 6 Oct 1999 15:56:48 +0200 (MET DST) Date: Wed, 6 Oct 1999 15:56:48 +0200 (MET DST) From: Reiner Klenk To: arts@space.twc.de Subject: Re: aRts 0.3.4 compile fails with audiosubsys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 260 Lines: 9 On Wed, 6 Oct 1999, Olli Sulopuisto wrote: > audiosubsys.cc: In method `int AudioSubSystem::open(int, int, int, int, bool)': > audiosubsys.cc:86: `errno' undeclared (first use this function) Add #include to the beginning of audiosubsys.cc Reiner From owner-arts@space.twc.de Wed Oct 6 19:56:07 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id TAA05498 for arts-list; Wed, 6 Oct 1999 19:55:48 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: from dot.crosswinds.net (dot.crosswinds.net [204.50.152.131]) by space.twc.de (8.8.7/8.8.7) with ESMTP id TAA05495 for ; Wed, 6 Oct 1999 19:55:45 +0200 Received: from dowen.templeoflove.net (ppp-120.tnt02.ffm.nikoma.de [212.122.146.120]) by dot.crosswinds.net (8.9.3/8.9.3) with SMTP id NAA85495 for ; Wed, 6 Oct 1999 13:57:44 -0400 (EDT) (envelope-from fromdusktilmann@crosswinds.net) From: fromdusktilmann To: arts@space.twc.de Subject: Cannot start arts server Date: Wed, 6 Oct 1999 19:55:16 +0200 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99100619570203.01386@dowen.templeoflove.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by space.twc.de id TAA05496 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 648 Lines: 18 Hello! I cannot get artsserver to werk, if fail with that message: --- initializing Arts Synthesizer object --- >> running as realtime process now (priority 50) >> since the scheduling policy is not standard, I assume it has been adjusted to fit the needs of realtime audio bind: Die Adresse wird bereits verwendet artswrapper: iop.cc:2397: MICO_Boolean MICO::IIOPServer::listen(class CORBA::Address *): Zusicherung »0« nicht erfüllt. --------------------------->8------------------------------------ of course I don´t have any clue about anything. So what´s the matter? cu -- fromdusktilmann@i.am http://i.am/fromdusktilmann icq #18937307 From owner-arts@space.twc.de Wed Oct 6 20:50:44 1999 Received: (from majordomo@localhost) by space.twc.de (8.8.7/8.8.7) id UAA05831 for arts-list; Wed, 6 Oct 1999 20:50:43 +0200 X-Authentication-Warning: space.twc.de: majordomo set sender to owner-arts@space.twc.de using -f Received: (from stefan@localhost) by space.twc.de (8.8.7/8.8.7) id UAA05826; Wed, 6 Oct 1999 20:50:42 +0200 Message-ID: <19991006205042.21398@space.twc.de> Date: Wed, 6 Oct 1999 20:50:42 +0200 From: Stefan Westerfeld To: arts@space.twc.de Subject: Re: Cannot start arts server References: <99100619570203.01386@dowen.templeoflove.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.85e In-Reply-To: <99100619570203.01386@dowen.templeoflove.net>; from fromdusktilmann on Wed, Oct 06, 1999 at 07:55:16PM +0200 Sender: owner-arts@space.twc.de Precedence: bulk Reply-To: arts@space.twc.de Status: O Content-Length: 1293 Lines: 35 Hi! On Wed, Oct 06, 1999 at 07:55:16PM +0200, fromdusktilmann wrote: > I cannot get artsserver to werk, if fail with that message: > > --- initializing Arts Synthesizer object --- > >> running as realtime process now (priority 50) > >> since the scheduling policy is not standard, I assume > it has been adjusted to fit the needs of realtime audio > bind: Die Adresse wird bereits verwendet > artswrapper: iop.cc:2397: MICO_Boolean MICO::IIOPServer::listen(class CORBA::Address *): Zusicherung »0« nicht erfüllt. > > --------------------------->8------------------------------------ > > of course I don´t have any clue about anything. So what´s the matter? Thats because artsserver is hardcoded to one specific port (yes, it's bad programming, and as you see, bad programming always breaks one day). You need to change that in shellutils/artscat.cc shellutils/artsshell.cc shellutils/midisend.cc ksbuild/main.cpp synthesizer/artsserver (search for 8888 and replace it with something else, like 8889). ;) Recompile & reinstall and hope that that one isn't used. I'll probably find a better solution for that some time. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- From fromdusktilmann@i.am Wed Oct 6 23:19:45 1999 Received: from demokrit.nikoma.de (demokrit.nikoma.de [212.122.129.5]) by space.twc.de (8.8.7/8.8.7) with ESMTP id XAA06489; Wed, 6 Oct 1999 23:19:44 +0200 Received: from dowen.templeoflove.net (ppp-134.tnt01.ffm.nikoma.de [212.122.144.134]) by demokrit.nikoma.de (Postfix) with SMTP id 58268565FB; Wed, 6 Oct 1999 23:21:44 +0200 (CEST) From: fromdusktilmann Reply-To: fromdusktilmann@i.am To: arts@space.twc.de, Stefan Westerfeld Subject: Re: Cannot start arts server Date: We