You are not logged in.

#26 2013-01-06 18:37:40

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

- Some resizing bugs/fixes for FSThost are being investigated right now (that affect certain plugins).

- FSThost-dev is looking into implementing one of my ideas on how to get VSTs and VSTi's that don't except midi program changes -> VST presets mapping correctly.

The solution that i have come up with (idea anyway) is to create fallback mechanism that would translate of midi program changes into sysex or raw midi data, which would then be fed to the plugin. (<--- which should work, i use sysex mapped to presets/VSTs on a daily basis, using my home-brew wiimote-baded session controller ~ ie: you press a button and all plugins change presets (using WiiMidi to program what midi-data XYZ button sends). So this stuff is certainly possible.

- FSThost has checks on startup that already see what XYZ plugin supports ~ so the detection code is already there.
- FSThost implements midi sysex, for re-call of settings (ie: you can do sysex loading/dumping). ~ this may be useful for 'bit juggling' program changes in the 'fallback' mechanism.

it's one avenue we are investigating to solve this problem, but there may be other ways to accomplish this.

note: there are a few really good VSTi's (well-supported in FSThost) that don't use program changes with Jack Midi / FSThost correclt, but DO use it with alsamidi..

The resize bug also needs to be fixed, FSThost is actually capable of hosting plugins like N.I Kontakt and other _heavy duty_ VSTs that require proper threading / only available in L_pa-Wine or a Receptor. (note: some N.I VSTs (not standalone) are affected by this bug, so it will be dealt with - one way or another smile

if we can pull off improving the support for program changes in plugins that don't support it ~ you will be able to use program changes with *all* VSTi/VST fx via standard midi (or the fallback mechanism).

this is just being looked at today, so I'll keep you guys posted on our progress.

Last edited by triplesquarednine (2013-01-06 19:03:46)

Offline

#27 2013-01-06 23:57:58

arkay
Member
Registered: 2008-05-23
Posts: 79

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

triplesquarednine wrote:

well, definitely aimed at improving a few components and having some patches merged upstream anyway smile

triplesquarenine wrote:

It would be hard to obtain quite the level of love that Muse' puts into it's host. But I am definitely all about improving all of our stack, where we can. Having a good implementation of wine and some apps that support it goes a _long_ way, though.

LOL smile  Just re-read my post.. Didn't mean to make it sound like you're solving the world of Pro-audio's problems all at once!

I know where you're coming from so what I meant was that any advancement in stability is a good thing (tm) smile

Not expecting a free Muse receptor for Arch by any means.  But the fact that the receptor does work so well is encouraging for vanilla Linux too.  Even if it's unlikely without dedicated hardware and the huge amount of direct fixes in their host.  It's all good though!

Cheers,

Arkay.

Last edited by arkay (2013-01-07 00:03:38)

Offline

#28 2013-01-07 01:05:34

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

arkay wrote:

LOL smile  Just re-read my post.. Didn't mean to make it sound like you're solving the world of Pro-audio's problems all at once!

Not all at once, but getting some of the biggest problems solved very quickly... Once wineASIO support is in place, we are pretty much good to go, with L_pa-Wine. (L_pa, as a project will expand on other things though, but getting tip-top support for VSTs/ASIO is my 1st / most important task ... obviously, i am working on other things too).

on the subject of WineASIO - there does exist a version, which _most likely_ already is using the code to bypass wineserver, that could probably be adapted for L_pa ~ the company Liontracs (out of Italy, makes synth modules, like Muse), they haven't published _any_ GPL'd code and i can tell you right now, i am 99.8% sure that they are in violation of WineASIO's license _and_ Wine's license....soooo, I have contacted them, personally and politely asked for them to publish the code that is derivative of wine / wineASIO... 

If they don't get back to me within X amount of time - i will continue to email them.... - if after a time, i am being ignored - they will be reported (by me), to the necessary parties involved, in order to force their hand... but i don't think it will come to that at all. Legally, they are _required_ to publish this code, so the ball is in their court. ~ Muse Research has been very helpful and i have a feeling Liontracs software is derivative of the work by Muse/Code-Weavers, so they better make it available smile

arkay wrote:

I know where you're coming from so what I meant was that any advancement in stability is a good thing (tm) smile

Stability /reliability of L_pa-Wine + FSThost vs. (vanilla wine(-rt) + FSThost/fst) has increased _GREATLY_ (at least 10x) ... obviously, i don't have numbers-  but I've been going through testing more and more VSTs and you would be amazed at how well this stuff runs now smile 

arkay wrote:

Not expecting a free Muse receptor for Arch by any means.  But the fact that the receptor does work so well is encouraging for vanilla Linux too.  Even if it's unlikely without dedicated hardware and the huge amount of direct fixes in their host.  It's all good though!

I expect once the project gets a little further along, you will be surprised at how well things do work... In fact, Windows plugins hosted in FSThost often work better than some native software, that is similar. (no joke --> i stopped using SooperLooper and have replaced it with a Windows one that has some features that are useful to me).

As someone who's been using a linux-powered synth module, rackmount (with both native & wineVSTs/wineASIO app support), in a _live_ setting (meaning i use it at jams, 2-3 nights a week. ie: must work _all of the time, no glitches), i've identified pretty much all of the big hassles when faced with this kind of stuff and i have thought long and hard for _many_ years on how to solve some of these issues. ~ L_pa is my execution smile

Archlinux will be a great distro to use with this stuff too ~ since binary distro's tend to be dis-advantaged when it comes to things like ease of adding custom patches to packages, license/distribution issues, etc.... It's actually one of the reasons i switched to Archlinux from Fedora (which i used for a very long time).

cheerz

Last edited by triplesquarednine (2013-01-07 01:07:03)

Offline

#29 2013-01-08 00:15:38

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

1. Something very funny _and_ very sad, at the same time;

- every single VST plugin that i have tested that has a "native" linux version / or port ~ runs better  in Wine-L_pa.

- this includes all of the Loomer plugins, Togu plugins, etc.

2. I've went on KVRaudio and begun testing a plethra of VST plugins in Wine-L_pa (some that never worked, as well as many i hadn't tried). ~ a whole boatload work very nicely (many more than i thought would). So, i am going to begin compiling a list of 100% working plugins - to post in my Wiki, once it is ready...

at the end of it all, i am guessing L_pa-Wine supports *substantially* more VSTs than upstream Wine, at this point. (and without the unix pipe code in upstream Wine, this will continue to be the case for some time).

anyway, i thought some of you may be surprised by the nativeVSTs vs. WineVSTs part and interested to know that there are probably hundreds of VST plugins that will now work in Archlinux using L_pa-Wine.

Also, I've decided to upload linux-l-pa to AUR ... as said before, i have removed some patches (based on feedback/issues), I will be adding a few, but not until i am positive they won't cause problems for users. It is available in AUR here; https://aur.archlinux.org/packages/linux-l-pa/

* read my comment on AUR.

nvidia-users will still have to go to sourceforge.net ... I'm crazy busy (with work, more than usual/unexpectedly) this week so i haven't bothered to fix nvidia-l-pa, but i hope to get some time over the weekend to learn _proper_ archlinux packaging standards... I also plan to have the Wiki (on SF.net) up by the weekend too. ~ i was hoping to have a bunch of pages up in the next few days - but it's _definitely_ not going to happen, because of my workload, right now. :\

any comments, help, feedback, etc are all very welcome.

cheerz

Offline

#30 2013-01-09 02:29:13

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

quick note:

I've sent another email to liontracs. (obviously, i did not get a response on the 1st email).

I've let them know Who i am / about L_pa:  Have requested their code, again - let them know this is my second request and that i would only be asking one more time, before considering this a violation of the GPL, a legal matter and would be contacting FSF legal team, Wine/Code-weavers and other applicable/affected GPL'd software projects, from which their codebase is largely derivative from...

~ I also let them know that 'the cat is out of the bag' on the in=house Muse/Code-weavers implementation of Wine and that unlike Liontracs, Muse has been very helpful and even had direct participation / contact + support for what i am doing.

So we will see what they do - but i have no problem spending as much time needed getting in touch with all of the right people, to have action taken against Liontracs if they continue to ignore me / don't publish their code relating to these FOSS/GPL'd projects.

who knows, they may be carrying a few more nice patches for wine to fix bugs too (that they didn't bother to submit upstream - which i will do for them).

Last edited by triplesquarednine (2013-01-09 02:38:16)

Offline

#31 2013-01-09 17:32:18

jhernberg
Member
Registered: 2010-08-23
Posts: 6

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I just built and ran the build posted on aur.  Most likely I'm doing something wrong, but I don't see it changing priority levels when programs are asking for it.  I used the following 2 environment variables: L_RT_THREADS=1 L_ENABLE_PIPE_SYNC_FOR_APP=1 but nothing appears to happen?  Maybe something wrong with the environment variables, or I need another one too?

Regarding what has been said about wineasio, I'd like to state that wineasio does not concern itself with priorities at all. In fact the callback function that jack calls once per period (at jack's priority - 5, because wineasio is a normal jack client) does absolutely nothing more than:

1. Copy the data from the jack to the asio buffers
2. Call the asio host program's callback function
3. Copy the data from the asio to the jack buffers
4. Return to jack

What happens in step 2 is totally out of wineasio's hands, and whatever happens in other wineasio functions, only happens occasionally, like when you open the interface or change buffersize, etc.

But I am looking forwards to trying the 3 most important Muse patches right now, if I could only figure out what I've done wrong...:)

Offline

#32 2013-01-09 21:00:13

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

jhernberg wrote:

I just built and ran the build posted on aur.  Most likely I'm doing something wrong, but I don't see it changing priority levels when programs are asking for it.  I used the following 2 environment variables: L_RT_THREADS=1 L_ENABLE_PIPE_SYNC_FOR_APP=1 but nothing appears to happen?  Maybe something wrong with the environment variables, or I need another one too?

Regarding what has been said about wineasio, I'd like to state that wineasio does not concern itself with priorities at all. In fact the callback function that jack calls once per period (at jack's priority - 5, because wineasio is a normal jack client) does absolutely nothing more than:

1. Copy the data from the jack to the asio buffers
2. Call the asio host program's callback function
3. Copy the data from the asio to the jack buffers
4. Return to jack

What happens in step 2 is totally out of wineasio's hands, and whatever happens in other wineasio functions, only happens occasionally, like when you open the interface or change buffersize, etc.

But I am looking forwards to trying the 3 most important Muse patches right now, if I could only figure out what I've done wrong...:)

Ah, was just about to post, after our email exchanges.

Ya, WineASIO is fine (in itself) ~ DAWs suck. ie: if you use windows DAWs -they may work well, they may not.

wine-rt is also going to be removed from L_pa-Wine when i move to wine 1.5.22 ~ since it isn't needed in an L_Pa environment... that will be the release ( hopefully) that will add some of the patches that i had merged into upstream wine. last week.

I'm going to talk to a couple of wine-devs that i know about the regressions in L_pa-Wine, as far as DAWs ~ maybe i can get someone interested into looking into it. (being as their was a lot of interest in the Code-weaver/Muse patchsets by many devs).

as far as using the variables, use FSThost since it works properly (as i told you in the email).

Right now, i don't have much choice but to say to those who use Reaper, etc ~ you might as well stick with upstream-wine + wine-rt hack ...

but if you want to use VSTs in linux/wine enviroment with native apps too - the _only_ good choice is to use L_pa-Wine (since it is a _much_ better solution and allows much better handling/support for windows VSTs, supports many more VSTs (with a few exceptions of 'resizing bugs' which will be addressed soon) and integrates nicer into a jackd/linux/wine environment. ie: it simply DESTROYS any other method for hosting VSTs.

jordan

Last edited by triplesquarednine (2013-01-09 23:01:23)

Offline

#33 2013-01-09 23:11:43

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I'd also like JH and others feedback on having L_pa-Wine install to a separate location (like /opt or something) and have it NOT conflict with wine/wine-rt..

anyway, gotta go.

Offline

#34 2013-01-11 21:32:18

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

As of commit 119, in FSThost (committed today).

the resizing bug is fixed. smile  Kontakt / absynth and other NI plugins can properly resize themselves (and Absynth does not crash)... Voxengo SPAN and other VST's also should correctly work with resizing in the 'embedded editor' in FSThost too. smile

For any plugin that is still problematic - please report it here or iva email to me.... and to get around any issue, you can use the non-embedded editor, like so:

1. launch VST in FSThost; 'fsthost -e foo'  (fsthost launches without VST window open)

2. uncheck embedded editor (the check mark icon)

3. open VST window (peice of paper with pencil icon).

you shouldn't have any problem after that. ~ but note: for the most part, you shouldn't even need to do that.

As another interesting note: *N.I Kontakt* is now (semi) supported in L_pa-Wine + FSThost

but as a critical note, for kontakt you _must_ disable 'multiprocessor support' - or you _will_ get xruns on 24/32/64th notes (with many voices overlapping) ~ this may be looked into later, but there are many other things on the go - so it isn't a huge priority for right now.

you might have to adjust other settings as well. But KontaKt is in great shape on my machine smile

cheerz smile

Last edited by triplesquarednine (2013-01-11 21:33:47)

Offline

#35 2013-01-12 18:40:06

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

L_Pa + FSThost(commit 119) + jack2 + Archlinux (64bit / multilib);

kontakt_3kits_and_ivory.jpg

kontakt: 3 battery drumkits (full jazz kit + full West african shakers/bells kit + full Asian kit)

Ivory: 8gig soundbank / jazz piano / lots of reverb + eq, etc)

both playing fast overlapping notes (all controlled via midi ch1) on all kits + Ivory ~ low DSP load in jack (13%). smile

working quite beautifully.

Offline

#36 2013-01-12 22:56:23

Brett Lyons
Member
Registered: 2012-12-29
Posts: 3

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Okay,

Diva demo (http://www.u-he.com/cms/diva) has a bug or two in FSTHost, in conjunction with requiring the -e -> uncheck editor box -> open editor process, the XS E Piano preset actually renders the synth soundless after it's selected.  I also tested it in a windows native host running under wine-l-pa, and it didn't go soundless after that preset was selected in that test case.

Offline

#37 2013-01-12 23:17:57

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

@ brett

I was more talking about resizing bugs... but as far as Diva - I'm already looking into some of it's issues (ie: already way ahead of you). I'm curious though, why are you using the non-embedded editor for a plugin that isn't even afflicted by resizing problems???  (you shouldn't need to do that at all for diva - since there is literally no point).

u-he stuff can be a bit dicey (i have licenses for ALL of their plugins). Zebra2 works perfectly here, but others tend to be problematic in varying degrees (for now). this needs more investigation, so give it some time smile

if you like though, brett (if you are upto it), you can put together a list and email it to me about plugins that you would like me to generally look into because of issues...

it probably would be useful, to me.

but be patient too, things like this take time.

Offline

#38 2013-01-13 01:53:15

Brett Lyons
Member
Registered: 2012-12-29
Posts: 3

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I don't use many vst plugins very much at this time.  I was just fiddling about and figured to try the most cpu-intensive VST I could remember as a test.  On a scale of 1 to 10, 10 being mission-critical and 1 being total non-concern, Diva working perfect with FSTHost is about a 1 for me.

if I come across any unworking plugins through a natural discovery process, I'll let you know but I won't be setting out to test them all systematically.

Offline

#39 2013-01-13 03:50:10

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Brett Lyons wrote:

I don't use many vst plugins very much at this time.  I was just fiddling about and figured to try the most cpu-intensive VST I could remember as a test.  On a scale of 1 to 10, 10 being mission-critical and 1 being total non-concern, Diva working perfect with FSTHost is about a 1 for me.

that's where i would put it on your scale, as well. ~ but note: Diva isn't even really supported on the receptor ~ and on top of that a 'demo' would never be considered past a 0-1 anyway. smile

that being said, Zebra IS at least a 9, for me at the moment. (in fact, it deprecated 2 plguins that i have been using for some time). it's just that some of the other u-he stuff is a bit dicey...


Brett Lyons wrote:

if I come across any unworking plugins through a natural discovery process, I'll let you know but I won't be setting out to test them all systematically.

nah, i was more thinking alongthe lines, of 'discovery' anyway. smile  the idea would be that eventually you may have some to mention...

...see, i have already reported some bugs in Wine over the last week (since having 1/2 dozen patches, including 2 of my own patches, integrated into wine) and i would like to focus on improving our VST support. L_pa-Wine does take care of many, but others still have limitations due to Wine, itself...

so like i said, over the next while, if you bump into things/problems... catalog it. take the name down of the plugin, in some random file ~ collect them, then once you have a decent list ~ send them to me - i will look into it. run them and report bugs smile

Offline

#40 2013-01-13 12:59:27

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

UPDATE:

the latest FSThost code (rev.123) now can handle VSTs that didn't properly allow midi program changes before. smile

you can do this, by launching a VST (that had this issue) with the -P commanline in FSThost;

fsthost -P foo

for any other VST (not affected) you don't need to add this ` it's _just_ for those types of VSTs that weren't working correctly in this scenario.

I've been testing it out this morning and it is AWESOME(!!!);

it totally solves one of the last most annoying usability problems, that i have had to work around for years, now. smile

Last edited by triplesquarednine (2013-01-13 14:13:35)

Offline

#41 2013-01-15 02:21:16

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I've updated the L_Pa Project pages (including wiki):

https://sourceforge.net/p/l-proaudio/wiki/Home/

there is updated info on how to use various things, including revised instructions for using L_ENABLE_PIPE_SYNC_FOR_APPS= ...

Wine-rt patch is also staying put and you will want to use it (as you always have) but with L_ENABLE_PIPE_SYNC_FOR_APPS with your Windows DAWs..

I've also been exchanging a few emails with a wine-developer who is interested in contributing, which is great.

as well, i have got a lower spec machine that i can use for some testing, now.

cheerz

Last edited by triplesquarednine (2013-01-15 03:18:44)

Offline

#42 2013-01-16 00:14:27

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Just now, i updated wine-l-pa in AUR.  I've added 2 new patches. (you can read my AUR comment about that).

I've also now migrated to my own L_pa-Wine environment to wow64 (mixed 32/64bit wine install in one wine prefix). it took a while to setup ~ being as winetricks required a lot of manual intervention to get all of the DLLs/software in place, that i needed / plugins often need... and i did have to repeat several steps with winetricks, again and again ... and then of course, i had to re-install ALL of my wine-related applications too (which was expected).

i'll be posting some info on how to do this on my wiki in the next day or so ~ but unfortunately, i have some work that i need to focus on this evening, that is far more important, if i intend to pay my bills wink

Offline

#43 2013-01-16 18:28:31

Army
Member
Registered: 2007-12-07
Posts: 1,784

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Great job dude!!

Offline

#44 2013-01-16 19:00:33

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Army wrote:

Great job dude!!

thanks man. smile  ~ but i do want to point out something very important -> that there are many users, developers, companies that have made all of this stuff work, well. (and they are the people i consider to be 'the real heroes' ). I'm just focusing on certain areas of interest / research / networking and identifying gaps that i see, from my own experiences. (and possible solutions).

things are slowly coming along though wink

cheerz

Offline

#45 2013-01-17 01:19:48

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I fixed my nvidia-l-pa packages and they are now available in the AUR and on SF.net.

EDIT: my nvidia-(beta)l-pa package is available at SF.net: https://sourceforge.net/projects/l-proa … rce=navbar  ...

I made the sillt mistake of uploading both nvidia-l-pa AND a matching nvidia-utils-l-pa package - which i didn't need to do (since you can just use nvidia-utils-beta instead). This lead to some confusion (my fault, wasn't thinking about it), as a TU thought my packages were just plain nvidia-beta packages, so without even looking at my nvidia-l-pa package, he deleted it :\  I've contacted him and am waiting for a properly reply/explanation on why he would delete a package in the AUR that isn't provided by any other package (nvidia-rt is only for stable nvidia release + linux-rt kernel)... I've explained all of this stuff in my reply/inquiry, so If i don't hear back from him in the next 24 hours, i'll hit AUR-general list and seek help to resolve the situation, before uploading again. - until then, just use my SF.net package.

I don't see any problem with the package, and even if there was, the TU should have told me that / and helped me with a guiding hand (which is apart of a TU's role) - which at this point, hasn't happened. so hopefully, in the next day or two, once i get this sorted out -  it will be back up on the AUR.

My nvidia-l-pa package is based on Nvidia 313.18 (released today). I tested the packages on 3 test machines, then uploaded them, once i was sure everything was okay smile

You can expect in the future that my nvidia packages will always be updated against the latest beta, within 24 hours of nvidia releasing the drivers (since that is how i consistently roll locally on my machines).

if you have any issues, report them to me.

thanks

Last edited by triplesquarednine (2013-01-17 23:06:36)

Offline

#46 2013-01-25 14:36:47

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

I've been quite busy for the last week or so - but progress is being made regardless (even if i haven't been posting).

a few things;

- some may notice that i updated wine-l-pa, reworked things a little and added (and ditched) some patches.  Locally, wine-l-pa has some additional patches that i am testing ( two look good for next release, but only affect wow64 users ).

- I've been spending some free time getting to know both wine code/internals and windows Api in more detail. ~ this has been very helpful in a few areas smile

- FSThost has had some annoying GUI behaviors fixed.  Importantly, there is no longer 'white-window' dead-space in the embedded window - this has been a long standing bug in FST (for years and years).  2nd, (which hasn't been commited yet, but i am using locally) - is VSTs in embedded window now can appear 'centered', rather than stuck in the left-top corner. - gtk.alignment has been implemented to kill both the white-space and fix alignment issues...

there is also another branch of FSThost, which implements a toolbar (and therefore hooks into your gtk theme better). it's not quite ready for prime-time yet, but shows a lot of promise (i am using both versions locally). in the gtk_toolbar branch - there is still a bug or two, like widgets being too tightly packed and i think the aligment between the embedded VST window and toolbar needs to be fixed of some dead-space - which probably requires using gtk.alignment or something similar to fix the issue... I'm sure Pawel or myself will figure that out.

- I've also got some kernel patches that may be of interest, they may not make it into the next linux-l-pa - but i _may_ offer them as an option (disabled by default), depending on a few factors - i'm in no rush to push out updates on the kernel though.

- my Wine-L_pa wiki probably has more info since the last time i have posted... I also am planning quite a bit more wiki info on Wow64 - however, that won't happen until i've familiarized myself with certain bits, in more detail...  I only use wow64 now, and i think it is the way to go for 64bit/multilib archers. wink

anyway, i just thought i would post an update smile

EDIT: NI KontaKt is now working with every CPU core on my machines (and so are other VSTs that are SMP, with one exception of Usine Stage VST - which still is only allowing 2 cores to be used... but i am not sure why that is - i may need to chat with the Usine developers, about a few things).


EDIT2:  regarding nvidia-l-pa - for now you will just have to hit my SF.net project page for that. I had chatted with the TU over the issue - but i haven't heard back from him on my last points - which need to be addressed / answered (by him) before i will put nvidia-l-pa back up on AUR...

it's not really a big deal though, so i haven't pressed the issue much and instead have been focusing on more important things... Having to download from my sf.net for nvidia is not the end of the world wink

Last edited by triplesquarednine (2013-01-25 15:11:57)

Offline

#47 2013-01-25 17:52:07

capoeira
Member
From: Vila Velha - Brasil
Registered: 2010-05-25
Posts: 447

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

reading

Online

#48 2013-01-25 20:56:14

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

capoeira wrote:

reading

(I'm) reading that you're reading wink

...Screenshot of latest FSThost SVN code for gtk_toolbar branch;

fsthost_gtktoolbar.jpg

I'm in the process of fixing my own gtk2 theme, so one button that looks 'inset' - is not supposed to look that way, and the CPU text color needs to be adjusted. ~ i just haven't gotten to that yet - but that's my gtk theme issue, nothing to do with fsthost...  The last issue i see visually (in fsthost) that needs to be fixed is the grey 'dead-space' between the VST plugin window and gtktoolbar needs to be fixed / aligned properly. (as mention before).

aside from that, all of the recent work done to FSThost is awesome. Much better than FST ever was - both visually and internally.

cheerz

Last edited by triplesquarednine (2013-01-25 21:42:08)

Offline

#49 2013-02-07 23:37:45

triplesquarednine
Member
Registered: 2011-04-12
Posts: 630

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Just a small update.

I've updated wine-l-pa on AUR (and sf.net). It has a bunch of changes / extra patchwork. Some of it is definitely not applicable to most users, imo. but some may be of interest - so i have included then. (they are just disabled by default). These patches range from wow64 related patchwork to Dtrace support (which is only of use for performance testing purposes), to performance hacks...

That being said some are enabled and fix bugs that i have encountered and/or just haven't been accepted into Wine yet - but are useful; DSound fixups (such as native float support, rework of mixer logic) to several bug fixes to problems, stubs, as well as a few other goodies.

The patchset/delta for L_Pa-Wine may look intimidating for this reason - but in reality, unless you enable a bunch of these patches - there are only a handful of extra patches being applied (that are relevant for end-users), the rest are available for testing purposes.

the nice thing though, is that some of the applied (by default) patches, do fix some issues for me (and likely anyone using the affected applications).

EDIT: Although not released yet, FSThost now has it's own icons (rather than using system ones). Currently, the icons are mostly 'place-holders' for icon work, that i plan to do, as soon as i can free up some time to do so. Here is a look:

gtk_toolbar_fsthost.jpg

I've also got some other wine / kernel related stuff that i am working on, but it isn't ready at this point and may not be for a release or two.

cheerz

Last edited by triplesquarednine (2013-02-08 01:36:04)

Offline

#50 2013-02-08 08:27:07

Pajaro
Member
Registered: 2004-04-21
Posts: 876

Re: L_Proaudio Project: Wine-L_pa + Linux-L_pa

Thank you for all your work, triplesquarednine. I believe that right now this forum is the most relevant place to keep an eye on for linux musicians.

Offline

Board footer

Powered by FluxBB