[linux-audio-user] Re: [ardour-users] jack_fst and gcc4

[Ken]

Dave Phillips wrote:

> Mark Knecht wrote:
>
>> On 10/22/05, Dave Phillips <dlphillips at woh.rr.com> wrote:
>>  
>>
>>> Mark Knecht wrote:
>>>
>>>   
>>>
>>>> On 10/22/05, Martin Wohlleben <Martin.Wohlleben at gmx.de> wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>> Am Sonntag, 23. Oktober 2005 00:02 schrieb Mark Knecht:
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>> On 10/21/05, torbenh at gmx.de <torbenh at gmx.de> wrote:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> On Fri, Oct 21, 2005 at 08:33:55PM -0400, Hector Centeno-Garcia 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>> Thanks! We help ourselves... that's the nice thing about open 
>>>>>>>> source.
>>>>>>>> With the -r option Crystal works for me now. What is this 
>>>>>>>> option for?
>>>>>>>> One plugin that I can't get working is the SRI_1010. It would 
>>>>>>>> be very
>>>>>>>> nice to have this one unless you know of any other free 
>>>>>>>> convolution
>>>>>>>> plugin. I tried with and without the -r option and I get:
>>>>>>>>
>>>>>>>> err:midi:MIDI_AlsaToWindowsDeviceType Cannot determine the type 
>>>>>>>> of this
>>>>>>>> midi device. Assuming FM Synth
>>>>>>>> gui_thread_id = 10
>>>>>>>> could not post message to gui thread
>>>>>>>> cannot create editor
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>
>>>>>>> hmmm... this looks like the plugin is trying to open a midi port by
>>>>>>> itself. try to configure wine so that it does not see any alsa 
>>>>>>> midiport.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>> Have any of you tried to use this one?
>>>>>>>>
>>>>>>>> cheers!
>>>>>>>>
>>>>>>>>
>>>>>>>> Hector.
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>
>>>>>>> -- 
>>>>>>> torben Hohn
>>>>>>> http://galan.sourceforge.net -- The graphical Audio language
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>> Hi all,
>>>>>>  I just got a few minutes to try xfst on my AMD64 machine. Did
>>>>>> anyone else run into this:
>>>>>>
>>>>>> mark at lightning ~/CODE/xfst-0.3 $ make
>>>>>> winebuild -o xfst.exe.dbg.c --debug -C. audiomaster.c fst.c
>>>>>> fstinfofile.c gtk.c jfst.c vsti.c vstwin.c
>>>>>> winebuild: unrecognized option `--debug'
>>>>>> Usage: winebuild [OPTIONS] [FILES]
>>>>>>
>>>>>> <SNIP>
>>>>>>
>>>>>> make: *** [xfst.exe.dbg.c] Error 1
>>>>>> mark at lightning ~/CODE/xfst-0.3 $
>>>>>>
>>>>>> I hope I'm doing this correctly. I put the Steinberg headers in the
>>>>>> vst directory and then ran make. That seems to be what the README 
>>>>>> file
>>>>>> suggests. There is also a file called readme.jack-fst which seems ot
>>>>>> be leftover from the older Jack_fst. Is that correct?
>>>>>>
>>>>>> Make does seem to want to run winebuild, and winebuild on my system
>>>>>> doesn't support an option called debug.
>>>>>>
>>>>>> mark at lightning ~/CODE/xfst-0.3 $ wine --version
>>>>>> Wine 20050930
>>>>>> mark at lightning ~/CODE/xfst-0.3 $
>>>>>>
>>>>>>  Did I miss some conversation about this?
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>>>> Hi Marc,
>>>>>
>>>>> I got the same failure with wine20050930. I downgraded wine to 
>>>>> wine20050830
>>>>> and xfst-0.3 compiled cleanly.
>>>>> You also have to change the vst header as for jack_fst. Otherwise 
>>>>> you get some
>>>>> error messages and make will "fail". I don't know exactly what I 
>>>>> changed
>>>>> exactly, but you can find the headers which I used attached to 
>>>>> this e-mail.
>>>>> I still got a failure message, during compilation but xfst works.
>>>>>
>>>>> good luck,
>>>>> Martin
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>
>>>> Thanks for the confirmation Martin. Backing down on Wine is not an
>>>> option. I'll wait and hope Torben will update the files to fix it.
>>>>
>>>> Cheers,
>>>> Mark
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>
>>> Hi guys:
>>>
>>>  Yes, I'm having the same problem with winebuild. The trouble is that
>>> the syntax for winebuild's options has changed from what Torben has in
>>> the Makefile. Unfortunately I haven't yet figured out the new magic
>>> incantation, but I did spend an hour or so on it this afternoon. Got no
>>> joy, same as you. :(
>>>
>>> Best,
>>>
>>> dp
>>>   
>>
>>
>> Dave,
>>   I'm only here for a few minutes this evening. In the make file
>> there seems to be more or less a a single invocation of winebuild that
>> has 'debug' in it. Can we just remove it?
>>
>>   Since the option isn't supported, and wasn't in the man page, I
>> don't know what Torben intended in it's use.
>>
>>   Anyway, part of this exercise, in my mind, is finding a solution
>> that works AND is maintainable out into the future. I suspect that
>> when we get past this we will see it as our first, small maintainance
>> patch. What's important is that we don't go backward with old Wine,
>> but always forward with new Wine.
>>
>> Cheers,
>> Mark
>>  
>>
> Hi Mark:
>
>  Unfortunately merely removing the --debug option doesn't resolve the 
> options problem. Winebuild now uses "modes" to define its actions, and 
> those modes are further defined by a set of options pertaining to that 
> mode. The problem now is that I can't figure out the right combination 
> of mode + option(s). The --dll mode requires a .spec or .def file 
> that's not present in the xfst package. The --exe mode requires no 
> spec file, but either it's not working as advertised or I'm still 
> missing something about it. One of those modes is supposed to be used 
> when winebuild creates a .c file.
>
>  Btw, this is wine-20050930, I think you're on the same version, yes ? 
> We should also be sure to test DSSI. As far as I can tell, the 
> vstserver project is dead, and the fst project is on a back-burner, so 
> perhaps we should concentrate on xfst and dss-vst with the latest WINE 
> releases ?
>
>  Also, I'm in the process of rewriting the VST+Linux tutorial, I'm 
> displacing the vstserver and fst material and putting up front new 
> material regarding my experience with xfst and DSSI. It should be 
> completed tomorrow (I'm not at my Demudi machine).
>
> Best,
>
> dp
>
seems a little emvarrissing that all the talented linux programmers are 
concentrating their efforts on running M$ based plugins.  should be a 
slew of dssi's by now, or maybe a reaktor killer...