Hey.
So, as the topic suggests, any EWQL PLAY engine users out there? Have you found a way to get the engine working working even somewhat well within ompt? If so, how?
I'm getting lots of weird crashes (not a huge deal), the wav writing won't work (annoying, at the least) and worst of all, ompt does not seem to store the instrument information within PLAY when used as a vsti, resulting in that I'll have to reload all instruments at the start of each session. Coupled with the frequent crashes, it makes the issue unbearable.
So far I've tried xlutop chainer and Art Teknika console to host the engine (as well as using play as just vsti), none with success. Apparently xlutop doesn't support PLAY and Art Teknika causes weird crashes. Any other workarounds anyone could think of?
Own them for EWQLSO but still use the Kontakt version since Pace/Ilok is the most disgusting form of piracy prevention by forcing the user to pay extra for it.
I remember soundsonline were giving away symphonic freebie that was with PLAY. Apparently it worked fine:
http://forum.openmpt.org/index.php?topic=3623.msg30330#msg30330
Quote from: KrazyKatz on December 04, 2010, 15:59:53
Own them for EWQLSO but still use the Kontakt version since Pace/Ilok is the most disgusting form of piracy prevention by forcing the user to pay extra for it.
I remember soundsonline were giving away symphonic freebie that was with PLAY. Apparently it worked fine:
http://forum.openmpt.org/index.php?topic=3623.msg30330#msg30330
Yes, if I had a choice, I'd revert to the kontakt version without blinking an eye, as play is generally buggy, and Pace/Ilok really is... bullshit. But then again, East West doesn't offer the kontakt version anymore, hasn't been since they made PLAY, even though there'd a lot of demand for the kontakt version.
Anyway, the older version of Play engine did work somewhat well (the one that the free package used aswell, I think), except that it ate way more resources than it was supposed to (I could only run 4-5 instances of play on my old system before everything would freeze).
I guess I could reinstall the plugins and try not patching them, as I'm on a much more powerful setup now, but before that I'd like to know if anyone's found a good plugin chainer / vsti host that would actually work with ewql stuff.
Sorry for the late reply! Have you tried using Xlutop Chainer as a "container" for PLAY? I had trouble with Kontakt 2 back in the day, and using Chainer fixed it all. Now I find that its advantages in flexibility and ease-of-use over OpenMPT's native VST handling keeps me using it. :)
It does cost, but there's a trial version that's fully functional... except that it won't save your setup.
Quote from: Ceekayed on December 04, 2010, 15:13:35
So far I've tried xlutop chainer and Art Teknika console to host the engine (...)
Whoops, guess I missed that... Thanks Jojo!
[to Board warning]: Board, I'm ALWAYS sure I want to reply to old topics...! That's just how I roll...
<ahem!>
Ceekayed, should've known you'd have some EW vsti's running on your rig..! Hope things are going well, fellow-oldskool-FB member. ;)
I myself finally will join 'the club' of EW users as I yesterday ordered the Complete Composer's Collection hard drive (yeah, and the ilok) which, I thought I might point out to any/all, is on a drastically-reduced sale price of approx. 75% off normal cost! I went just to get symphonic choirs at $445 and spent $800 on 7 components, instead. :) Hopefully I won't have too many problems getting all to work with OpenMPT... but if I do (and figure out how to get them/it/whatever working...) I will post back with hints. ;)
But hey! Anyone who's been thinking about purchasing anything at all from EW's superb line...: You might head over and check it out...
quickly! The special ends 4/30.
No, I am not a paid salesperson nor do I receive special treatment of any kind for plugging EW.. ;P
I'm not going to buy but still I'm rather curios on how many GB's are we talking about?
Don't kill yourself buying it right away. Soundsonline constantly have sales and this one has popped up a few times. Join their mailing list if you are interested when they have offers.
Although it's worth noting that this particular deal is the cheapest I've seen.
True -- appologies, I was mistaken by vague language (yep, that's my story and I'm .. yeah.) -- the shipping being free was April's special. Sorry for any undue alarm/rampant purchasing I may've caused.. ;)
Rakib -- the CCC comes on a terabyte SATA hard drive and of that, only about 165GB free space remains. It should be noted that all of their products' sample and instrument data comes on the drive as well; yet you need proper licensing (via a "frustratingly confusing and/or easy-to-mess-up install process-which-behaves like licensing errors so as to mislead you for hours" licensing process via the Pace iLok) to get the appropriate library(/ies) to work.
Received mine a week ago and only today got ALL of mine working. Same issues here; random crashes, confirmed on PLAY not storing instrument/settings internally (as other VSTi's do whilst laughing gingerly in PLAY's general direction). The maddening thing for me, though, is that there's no log of the crash in the Application error/event log (which would seem to be generally helpful at least)... Wish this could occur via OMPT at least (feature request if you wanna mess with it..?) but should definately occur from PLAY's side as well (as the crashes happen, for me at least, more often when tweaking a dial [for example] in PLAY than while working in OMPT).
'Course I've not yet ruled out my extensively customized 'rig' nor any drivers yet... but with similar problems (even so's forums host dozens of steaming posts about PLAY's instabilities, cross-platform..) in abundance I'm not sure how much energy I'll devote to system tweaking my box (which was fine until PLAY came into the picture other than the occasional 'burp' or MIDI control driver panic)... and I don't consider my 'setup' to be anything overly extravagent on the resources, either:
Dual core (core 2 duo)
Win XP Pro SP3 2GB RAM
2 analog synths (can be MIDI controllers; SH-201 driver/lib sft loaded, Micron isn't currently) and an M-Audio MIDI controller (keystation61) with an Akai LPD8 midi control for knob tweaking and (lastly) "Rejoyce" (not usually running..) to enable vector control over VSTi's via an old analog stick on a gamepad.
Edit: All the MIDI HW is 'yoked' via Maple MIDI as I used to run GigaStudio [which wasn't compatible with Midi Yoke].
Granted, more RAM and faster CPU are looming purchases (as would be 64bit OS) but even small samples via PLAY cause high rates of crashing.
If I ever come up with anything helpful I'll post back -- and would appreciate the same from other PLAY users out there..!
Aiight.. been (painfully) attempting to play with the Bösendorfer 290 (friggin huge -- crashes often!) all evening and found a few 'tips' for others which MAY prolong the compositional experience...:
- OMPT 1.19.01.00
- PLAY 2.1.2 (apparently earlier versions of either tool were reported to 'work fine' by others in another thread (linked above by KrazyKatz) -- however, this combination definately has issues..!
PLAY settings (some of these are so low due to my hardware/resources; yours could be higher and get decent/better results, but lower definately seemed to increase stability for me hence the following recommendations):
A) Turn voices all the way down, and set engine to lowest possible setting, followed by an engine reset
B) Reduced 'CPU Overload' to 60% (didn't play with this one much lower; higher settings weren't well received I can say, though..)
C) Reduced 'Round Robin Reset' to 8 (lower seemed better here, too).
The above settings will limit how many instruments/patches (and/or PLAY instances) you can run at once to be certain; however, being that my keyboard skillz don't yet approach the level of technique required by stuff I compose while tracking, I sometimes find it beneficial to nab audio recordings of certain instruments and then mix them together into the final song's blend, rather than aim to have a 100% completed and playable tracked file. Also lets me play with more effects and filters than PLAY by itself allows. ;)Tips while Tracking1) Avoid clicking on a pattern (or order) when you have the PLAY window/plugin loaded and open. This caused a crash more often than arrowing through the pattern data to get to the next pattern.
2) Use 'Pause Song' and then 'Stop Song' to end playback and begin editing. Stopping and editing straight-away seemed to cause more crashing badness than the other way 'round.
The thought struck me that the tips above may suggest and/or even be related to graphical conflicts amongst drivers/interfaces on some systems (especially mixed-branded cards in multimonitor setups, like mine), and also whether or not you've set OMPT to "show prev/next pattern data" and "follow song by default." It is possible that some of the graphical routines don't 'gel' together with PLAY's code/graphics, which could account for some of the 'random' crashes (with small instrument patches loaded, or even when nothing's playing for example). I hadn't gotten around to visual themes and graphical tweaks yet; if I make headway there I'll follow up more.While this info (in part or in whole, perhaps) may seem trivial regarding performance of PLAY in OMPT; I can thankfully state that I found stability enough with the beast of the piano which Bösen is, to (at long last..!) complete a nearly 2-minute piano segment successfully.. ;) I'd been fighting with it the better part of the day. The project was simply to replace a lesser Grand sample with Bösen... Wouldn't have thought it'd have taken me a day. :/
In moments like this, I'm happy that my sample library is probably 50 times smaller than yours, but at least it doesn't crash and it goes well with OpenMPT and it doesn't come with any stupid DRM... :P
Christofori, sincere thanks for that extensive follow up on your experience. All the info we can get will prove vital as PLAY libraries grow. And I hope that you get a lot of "PLAY" (utter morons) out of your libraries in spite of conflicts.
Eventually I will have to bite the bullet and buy the damned Ilok. I even already own the EWQLSO Platinum edition for PLAY in addition to the Kontakt version. But it just sits on my shelf because I didn't realize I needed an Ilok until after I had it shipped. The small print of course.
Why hasn't anyone just cracked PACE yet? Is it that sophisticated a defense mechanism or just lack of demand? If there were a crack, I'm sure there would be less software/hardware conflicts.
Note: I believe in paying for software, but I don't see issue using a crack to replace a dongle if you already pay for the software which I have... and can't use.
Jojo -- Uh, gee buddy, thanks for the encouragement there..! :P
KrazyKatz -- And thank you for your kind words. ;) I used to run the IT department for a fairly large-sized decor manufacturer (outsourcer is more accurate perhaps... they designed some goods, but many more are licenced goods purchased from local manufacturers in China, the bastards.. they took our jobs!!... heh, yay south park!!... can ya tell I've had a long day? Long day = long run-on tangent.. back to topic seems to be called for [a while ago, perhaps]) with several locations (showrooms at furniture/decor markets, mainly) in the states as well as those in China mentioned in the tangent... so you can imagine I try to examine everything accutely (and at great pain to my psyche sometimes, but I usually get over it quickly, lol). Thus the tangents.. attention to detail, anal retentiveness, whatever. :P To put my sickeningly overgargantuated and admittedly exaggerated appreciation of vocabulary to rest (exhuberatingly lifting the spirits of any poor sobs which find themselves reading this, no doubt!), I put it bluntly: I am a nutcase. A nitt-picky nutcase. :) Who likes to babble. :P
Seriously, skip that paragraph up there ^^ if you want. ;) Except for the part thanking KrazyKatz of course. And more seriously, comes my grim reluctance to admit I still have crashes with Play. I did end up loading the piano into a stripped down (virtually sample-less) module file, as the file I'm working on currently (samples and data including vst settings and all that jazz) is about 280MB -- so (even though there were still occasional crashes) I managed to edit-save-edit-save long enough to end up with a WAV of the piano sample I wanted, playing the tracked data (all other info had been stripped to avoid bogging up the RAM needlessly, as I HAD to get the piano part into that sexy piano patch!).
Currently, most recent crashes have occurred whilest browsing patches for drumkits to use in this song. If anyone else using OMPT+PLAY comes along with crashing, heed some advice -- do your general auditioning in the standalone PLAY, or even render your module to WAV before loading the PLAY VST (so you can play the module in a media player while auditioning samples in stand-alone PLAY) till you find a good combination. If somehow this issue doesn't ever get fixed, I doubt I'll use alternative software to OMPT (except perhaps for sequencing PLAY components I'd then layer into my modules) because I don't want to wrap my mind around something new (call me crazy, but I'd decided it was already cramped in this mind a LONG time ago.. lol).
Much of (if not all of, come to think of it...) the orchestral parts in my current song were done in GPO4/Aria due to the crashing of PLAY (by the way, ARIA works nearly flawlessly!).
KrazyKatz, you do bring up an excellent point, which inspired a neat (albeit unrealistic, unfortunately) idea -- Why can't sample/library/vsti/whatever developers license their products to software (DAW/sequencer/notation/etc) developers, so the bugs and kinks can be ironed out? Likely some of the giants already do this, but what possibly would be the harm in having say, in this case, an EWQL PLAY product (or, all of them in my mind..) that was specially licensed ONLY to hardware existing in the development environment of said software developers? That way, the interests of the lib dev would be secured, and the general sanity and well-being of artists using their preferred software would be earned (not to mention the nice feeling developers would have that their products are truly fairly 'universal' in application to the multitude of software solutions in this world for we peons to chose from...)...! [In short: Why can't they just give you the CCC and an iLok for free so we can test/fix/collaborate this issue 'till resolved??!] ... but yeah, lest I forget this world revolves around money. I know. [sigh]
Perhaps it's worth a shot to ask them..? I'd be willing to assist, providing (if nothing more...) a vast array of overly inflated vocabulary (as well as my earnest and pleading wishes for it to just work without crashing randomly).. ;)
[(edit) I am also going to lower my max poly per LPChip's suggestion in this post: http://forum.openmpt.org/index.php?topic=4365.msg36019#msg36019 -- will see if it helps. Unfortunately I'll still need 128 but that might free some weird bottleneck, dunno. I'd not changed my poly setting since switching to so many VSTI's and am a bit surprised I hadn't thought to check it already -- thanks LPChip et all, and "Fate" (God) for connecting the dots via forum browsing randomly as I had been! :)]
Quote from: christofori on May 10, 2011, 04:45:52
Jojo -- Uh, gee buddy, thanks for the encouragement there..! :P
Anytime! :P
Quote from: christofori on May 10, 2011, 04:45:52
[(edit) I am also going to lower my max poly per LPChip's suggestion in this post: http://forum.openmpt.org/index.php?topic=4365.msg36019#msg36019 -- will see if it helps. Unfortunately I'll still need 128 but that might free some weird bottleneck, dunno. I'd not changed my poly setting since switching to so many VSTI's and am a bit surprised I hadn't thought to check it already -- thanks LPChip et all, and "Fate" (God) for connecting the dots via forum browsing randomly as I had been! :)]
Sorry to disappoint you, but that won't be much of use for a VSTi-only song. The max polyphony is mostly affecting virtual channels, and you don't have those with VSTs, just with samples. Basically, you need the polyphony to be as high as your number of channels in the module as a minimum, but the rest is mostly optional for VSTi-only tunes. And let's face it, ModPlug was made to run on Pentium 1 and slower machines, so the sample mixing part really shouldn't be the limiting factor if you are using something like PLAY.
...Didn't help.
Jojo: be aware that I'm also using my own samples in various sections. I'm a mix-mash of samples and VSTi's at the moment. The reason: I combine samples (overlay them is more accurate..) via tweaking settings in their channel data until I get the sound I want (which is a 'tracked' blending of multiple samples to form one voice) -- which I don't care to find another software to use to continue enjoying this wacky creative freedom MPT/oMPT has given me (freely, I might add!) for years now. That being said, I also do indeed use 128 virtual channels (topped out at 121 I think..) so the polyphony setting is needed in my case. ;)
=-=-=
I have, however, made headway that should help, developers (perhaps..!). I've:
1) Found something that in my particular module file I can do which ALWAYS generates a crash (if 'play_vst.dll' is unloaded, change 'ALWAYS' above to 'NEVER'... heh. There's our first clue if we didn't already know we're talking about a problem with PLAY working in OMPT. Yep, mastering the obvious again huh! OK, on to #2...)
2) I managed to tweak my system so as to recover OMPT's (lost somewhere along the way, been a while...) ability to use dwwin.exe to report crashes -- so now, I have fault information! To save space here, I will post the XML file it wanted to submit:
http://www.christofori.net/ompt-play/8e8a_appcompat.txt
[edit: you may need to right-click, save-as to get the text/data depending on your browser...]
... Anyone wanna tackle it? My brain is too sleepy to follow it at the moment, but I'll dig into it tomorrow if I can. Hopefully there is something therein which might begin to shine a light onto a resolution to this crash.
Oh, I also went ahead and submitted the error to MickeySoft in case anyone wondered .. (for what good it'll do) :P
Is there a demo version of PLAY to test with, and can you reproduce it in that version, too?
I don't think the DrWatson log is of much use to me, however if you happen to have Visual Studio (2003 or newer) installed, we could probably get a little debugging done...
I did some searching (admittedly only about 10 minutes, which should be enough IMO..) and cannot locate a demo for PLAY.. which also makes sense as EWQL says all products using PLAY require activation and licensing via iLok (which means, they're only releasing AUDIO demos -- you can hear what it sounds like but cannot experiment with it on your own before buying in other words).
I do have Visual C++ 2005 redist and VC++ 2008 redist installed from something (evidently) which required it at some point... however if that's not component of Studio and/or can't be used for the debugging I'd need to do to provide you with helpful info, then no, I don't have it. I haven't searched for the installer yet (more on why in a moment) -- is it free? If so (and if the "more" doesn't pan out...) I'll of course install and provide you with anything you need (other than my iLok and CCC hard drive of course.. lol..) to help get this worked out. ;)
MORE: Recently discovered "Bidule" and 'midibag' and those appear to be capable of some crafty routing tricks I'm thinking I might be able to employ, so as to either route audio OR midi data in the proper directions so as to use the standalone version of PLAY rather than the VST when working with OMPT. I'll let you know how this turns out; as if it 'fixes' the crashing issues I'd say we probably don't need to do any debugging (how many people are really going to be using OMPT with PLAY anyway? Most PLAY users use other software, and most definately aren't trackers or from a tracking background, which would want features of trackers for purposes like mine mentioned an above example [samples AND vsti's]). Although I'll agree that adding yet another piece to the 'puzzle' (not to mention it taking my system resources in the process...) isn't really ideal; yet if it solves the dilemma, I'll definately be happy.. ;)
Will post a report on the experience ASAP. ;)
Preliminary report: so far only outputting MIDI data via the VST2MID component of midibag into two seperate instances of stand-alone PLAY (each instrument [so far, only a couple at a time] on it's own unique MIDI channel, with both instances of PLAY set to use the same MIDI port) -- though I have to select different ASIO outputs for each of the players and OMPT (ASIO4All, directX ASIO, and my sound card's ASIO driver) -- all of which are outputting on my sound card's '3-4' outputs (using a Delta-44 audio card w/ 4 outputs). As I run my outputs into a small mixer, the system sounds and media sounds I generally map to '1-2' (fed into a stereo mixer channel) and of course '3-4' in a seperate mixer channel (labeled 'Tracker' hehe). Why do I list the mixer? You'll see (it has to do with how I can end up with a WAV file of my song when I am finished, considering I'm using multiple ASIO drivers at the same time...). Now, then... here's where it might get confusing; as I'm going to list my overall setup mapping/connections on the PC (I won't go into the hardware synths and other mixer channels as that is extraneous to this discussion...).
I am using Marblesound Maple MIDI to capture input from my MIDI controllers, and have the keyboard on port 1 and also have an Akai LPD8 (knobs and pads) on port 2. Using Maple you can 'layer' channels/ports onto their own port; so I've elected to output any/all hardware MIDI data using Maple's port 3. Then in OpenMPT I set the input port to port 3 -- so any MIDI data captured on either hardware device can be fed to the tracker (including of course VSTi's). Then since I'm using midibag I can output MIDI data from channels in OMPT using Maple's midi port 4 to the instances of PLAY. Now, since using multiple ASIO drivers I can grab all my actual sound input (including samples in the tracker, MIDI data played through the tracker to PLAY, and other VSTi's I might want to load [softsynths in my case generally..]) on ONE mixer channel, I then have the ability to route it into one set of inputs on the sound card via my ever-crafty cabling and of course the mixer (well, okay... it's more due to the mixer than my cabling, lol). This is how I capture the WAV version of whatever I'm working on (which then .. well you get the idea). I've actually stopped using the WAV export functions of OpenMPT some time ago because this 'creative routing' was easier than exporting a WAV and then layering other audio (a hardware synth or vocal track, for example) over in other software. Additionally I've found it to be buggy once or twice (likely the encoder I think, can't remember now what was up when I last tried it, but it's of no consequence really).
After all of that, the preliminary findings: Pretty good! Though I haven't loaded a ton of instruments into either PLAY instance, I won't want (or be able, for that matter) to. I'll have a maximum number of 16 instruments I could load, due to the limitation of 16 MIDI channels (unless I wanted to eliminate one hardware piece [unlikely]... besides I'd need a new computer before thinking of approaching the full 16 anyway, I'm pretty sure..!). But I have not yet attempted to load a massive instrument into PLAY either (if you'll remember I rendered the piano to it's own WAV file which is just played in a channel of OMPT as a sample... which is still resource AND file-size intensive but was the only way to address the crashing issue I could come up with at that time... since the piano's SO big I don't want to retrace those steps at this point anyway, also due to the time it would cost me to even try). So, while this setup is likely not going to be at all common to other users, I would imagine that any trying to use OMPT with PLAY would find it helpful that I went into this detail considering that they likely would already have (or could easilly obtain) a small mixer to make it all possible for them, too. The mixer I have by the way, is a mackie Tapco Blend6 which actually/surprisingly allows me to use (as inputs): 2 different stereo hardware synths, 2 seperate stereo PC outputs, and a microphone whilst being able to creatively route just about any combination of those back into 2 seperate stereo PC inputs if I want (allowing multi-channel recording). So I could easilly play my track into headphones while singing into a mic (avoiding bleed-over of my output into the mic, of course) and record the L-R track as channels 1-2 in Audacity while setting the mic as channel 3 in Audacity -- enabling ONE recording session which would easilly produce 2 seperate end-products (a 'studio' track with me singing, and one without me singing, for example). Of course, bigger/better setups give you many more capabilities... but any little 'indie' artists like me might be quite happy with these kinds of capabilities. (edit: OKAY, I 'went there' about the hardware/mixer after all... hopefully done in a way that actually IS relevant to this discussion!)
All that said, I suppose one could call my setup "the Frankenstein-of-a hardware+software DAW" if one so desired.. ;)
NOW then... let's just hope I'll get to continue being happy with the PLAY performance, as I cautiously continue adding/experimenting/composing...! >:)
Quote from: christofori on May 11, 2011, 04:18:23
I do have Visual C++ 2005 redist and VC++ 2008 redist installed from something (evidently) which required it at some point... however if that's not component of Studio and/or can't be used for the debugging I'd need to do to provide you with helpful info, then no, I don't have it. I haven't searched for the installer yet (more on why in a moment) -- is it free? If so (and if the "more" doesn't pan out...) I'll of course install and provide you with anything you need (other than my iLok and CCC hard drive of course.. lol..) to help get this worked out. ;)
No, the redistributables are something different...
Actually I think there used to be a free version of EWQL available some time ago, but I just ripped some samples from that and deleted the rest... :\
There was a free demo of symphonic orchestra back when it first came out, but that was a few years ago.. it's apparently no longer around anywhere as I had problems finding it.
Running the setup I mentioned in my previous post I've had 1 hardlock (which in and of itself isn't common really with this PC, but also is not unheard of, and happened out of the blue before either Play or Aria were installed, so I'm discounting it). Other than that, pretty darned good performance. :D Finally!
[tangent] Finding midibag was a complete random chance-event (if you believe in those kinds of things, anyway), too.. I think somehow I'd ran across Bidule on EW's forums and searched these forums for it to see if anyone'd tried to use it with OMPT, and found *one* post, where I believe lpchip was recommending midibag to that person... But yeah -- I knew if I kept at it long enough I'd eventually see something that would make productivity possible again. ;)
* * *
I should also note that I've gone pretty much exclusively back to only one stand-alone instance of PLAY as one of the ASIO drivers I'd been using was causing occasional static (was a cheapo-software driver or mismatched version files, or having 3 ASIO's actually running and working at once... pick yer poison!)... ;)
[end_tangent_thingy]
So, composing has returned to priority. However if the Studio tool/app/component or whatnot that I'd need to help debug is free (something causes me to doubt so..) I'll still be happy to download, install, and help out. I realize someone else with the same predicament might not want to go all 'techno-geek ninja' on their setup as I've done.. lol. Let me know, and I'll do all I can to assist. ;)
I think it really was just a temporary offer, but there was an EWQL Orchestra Free edition one or two years ago. But that's gone also...
And yes, midibag is pretty useful. It basically makes up for OpenMPT's lack of MIDI Out, and because it exists, there's not much need for actually implementing MIDI Out support anymore (or just implement it as some kind of "internal" VST effect). There are just so many advantages to have it as a plugin "device"...
True -- no need to add something which would be extraneous. Speaking of midibag, I'm getting some latency issues on some drums -- so I've been testing various different configs and whatnot, yet again. ;P
This brings me to another question which is somewhat related, in a way. In OpenMPT under sound card setup, how difficult would it be to allow the setting of ASIO outputs as an option? If I set my audio card driver as the ASIO for OMPT to use, it ONLY goes to output 1-2 -- and though I've a few other software 'tricks' I can run to try switching it, none of them have worked. Most other apps (all I've seen anyway) allow the selection of outputs for systems with multiple sound outputs. I'd love to see that added...!
And to the reason I came back this morning... I'd like to continue working towards finding a stable solution for PLAY as a VST within OMPT. Is VS the only app you can suggest I would need to assist in that process? Could I do what would be needed with a trial install and if so, assuming 2010 Ultimate Trial would work..? Please advise. ;)
Quote from: christofori on May 14, 2011, 14:29:31This brings me to another question which is somewhat related, in a way. In OpenMPT under sound card setup, how difficult would it be to allow the setting of ASIO outputs as an option? If I set my audio card driver as the ASIO for OMPT to use, it ONLY goes to output 1-2 -- and though I've a few other software 'tricks' I can run to try switching it, none of them have worked. Most other apps (all I've seen anyway) allow the selection of outputs for systems with multiple sound outputs. I'd love to see that added...!
I have changed some lines in the ASIO code to see how easy this would be possible, and I instantly managed to get ouptut on Channel 3/4 of my audio interface, so yeah, this could possibly be implemented. Though if you want to be sure that I won't forget about it, you should create a new ticket on the issue tracker (http://bugs.openmpt.org/) for that... :)
About the issues with play... Well, we could try setting up a remote debugging session first. I have never done that before, but it could work out.
[Issue Tracker] Dun.
[Remote Debug] Perhaps... but I'll install Studio 2010 trial if you'll provide the info I need to get you the debug stuff. I know you're just dying to see more of that EWQL stuff; so check the issue tracker... I put a goodie in there for you. ;) No drooling!
[edit] The Play VSTi crash behavior is still the same in new release (version 1.19.02.0) just FYI -- no surprise I guess, didn't see anything about the VST code in the update notes. Just thought I'd post and let everyone know I did try it as a VSTi again, using the latest/greatest! Back to slight latency problems... ... BUT ... it just occurred to me: playing back my track was fine in the new (and old, come to think of it...) versions; it was when moving around the editor interface that the crashes would generally occur. I might just switch instruments back and forth for editing and mastering (edit them with above config, sending channel data as MIDI via midibag; record/master them using the VSTi for playback with no lag! Can you tell I've been working on lyrics? lol... gotta love things that rhyme.) :D Well, there's the next step of the workaround for now. I'll still check back in to see about helping test the VSTi as there might be a couple other tracker types wanting to use Play with OMTP (other than ceekayed and myself).
Quick update today -- playing around here and there (or forgetting to switch back to the 'midibag' setup to edit the track, to be honest.. hehe) I've noticed that MOST crashes with PLAY loaded as a VSTi occur when changing pattern/order and/or manipulating the pattern/order in some fasion. If I edit everything in OpenMPT under the 'midibag' setup (sending to PLAY via MIDI in other words.. see previous postings) it runs fine; but then I can also save the file, then add the PLAY_vst and configure my instruments to use it rather than midibag's VST2MID plugin and get good playback each time. It's only after I quit playing and go to editing that there are issues. Could there be something funky going on within the GUI of OpenMPT that causes PLAY to freak (thus crashing OMPT) I wonder..? Either way I still want to try helping to debug as switching just to hear in-sync(samples, not the band.. ha) results is a bit of a pain. I realize, Jojo, that the problem could be the converse (the PLAY graphics do something weird to OpenMPT) but I'm also starting to wonder if OMPT is sending out some data to VSTi's when patterns are edited or manipulated.. well other than output via the VSTi channel.. does any of this make sense? I guess I'm asking if OMPT sends sysex data or any non-MIDI data related to pattern/order/row/channel/etc. positioning. For fun I'm also going to change some OpenMPT setup options (play notes on record, etc) related to the sound playback and see if I get more stable results ('course what fun is recording something you can't hear?)
I'd guess that the crash happens somewhere in PLAY, but we can try to do some remote debugging if you hop on IRC later.
In PLAYing (ha.. this is just too much. They HAD to call it play?! Irony kills me!) with it more, I believe the PLAY VSTi is not releasing the audio component properly. I had NO problems editing when I disabled the following options in OpenMPT:
* Play new notes while recording
* Note fade on key up
(I chose them on a hunch if you will)... but then I set up a new instrument, and auditioned it through OMTP as I would any VSTi, with my Midi HW enabled and active, and played some notes. Worked fine. Then I tried playing the module itself; crash. Seems PLAY isn't handling the audio streams properly IMO. I began wondering (or, 'hunching' .. sounds odd but I won't remove it, I can't be the only one to know I'm crazy!) if it were sound stream related because, when using ASIO4ALL as the output driver for OMPT if you play back after editing pattern data (with the above turned ON) you get no output, usually. So then you pause and restart playback to get the A4A driver to go. Something similar (where the stream isn't released properly) is happening with PLAY where it sometimes faults while entering notes and sometimes while simply clicking on an order in the ordlist. It COULD be sound stream handling code in OMPT I s'pose; as it seems to be 2 'streams' at play in this situation; one for general playback of the module/pattern data, and one for note entry (if this is the case, therein lies the problem and now that I think on it more, could be directly related to using ASIO4ALL). I may also try switching back to my card's ASIO driver (even though it'll mess my output scheme temporarilly.. lol..) and re-test to see what happens. Perhaps it may end up being a problem between Play and OMPT when ASIO4ALL is in the picture (don't know if this was the case in ceekayed's setup for sure...) -- but this could help explain how SOME people had SOME version(s) of PLAY and OMPT working while some don't. I'll check back in a momtn with a yes/no. :)
Still crashes, just not AS much.
Does the '2 streams' thought inside OMPT make sense? Did PLAY go against the cardinal rule of Ghostbusters and cross the streams on me? :P
Quote from: christofori on May 15, 2011, 20:32:26
* Note fade on key up
Shouldn't change anything, esp. not with VSTis. It's very possible that PLAY can't / doesn't want to deal with OpenMPT opening and closing the output buffer all the time, and I don't even think that the audio driver should be involved in this problem at all (since VSTs never see where their output goes). However, as said, if you hop on IRC, we can try to start a remote debugging session. I have no idea whether it will work, but it's worth a try.
.. I was dragging my feet with that as IRC is on my other machine, not this one. I might be able to remote to it.. you don't need them running on the same pc do you? Other reason - I have 3 monitors in a funky L-shaped arrangement, dunno if it will give you headaches.
No, IRC would just have been faster for communication. However, your studio PC has to be connected to the internet for debugging. And you can use the Mibbit client on openmpt.org for IRC if you don't have a client installed anyway.
Yay Christofori.
I gave up on trying to get the stuff working on ompt a while ago, I just record live samples if need be, I've also ripped most of SD2 to samples since percussions are easy to use as sample-based.
Anyhow, I did hear a wild rumour that Vienna Ensemble Pro would work flawlessly with PLAY, now the question is, does Vienna Ensemble Pro work in ompt flawlessly? It's another piece of a crappy drm protected software without a demo (or well, there *is* a demo, but it requires Steinberg's dongle), so can't test it without spending a few hundred bucks for another piece of a software that might not work. >_<
So if anyone does happen to have VEP, please test it by chaining some vsti's through it to ompt and see how stable is it and if all the data gets saved as supposed to. Vienna's customer support has been a complete bitch, they're obviously not interested in getting my money.
Well, you've got all I can give ya on the "incompatible/buggy vsti's with OMPT" arena; as my budget for samples was more than used for Garritan (ARIA works great!!!!) Personal Orchestra 4 and the EWQL CCC (w00t! I since have added a Focusrite Pro 14 to my setup and using it's MIDI I now have flawless playback AND creation.. no more swapping back and forth!). On a side note when using the Focusrite's ASIO driver and attempting to load PLAY [edit: referring to the VST version inside OMPT here, folks!...] it crashes much sooner than before. If for some reason I wanted/needed, I still have my trusty (underpowered in comparison.. muahaha..) Delta 44 going though nothing's running in/out of it now... so I could use it as another ASIO source for fun I s'pose... but alas, I digress (and then some!) :P
Other day I posted a support ticket on soundsonline.com for the PLAY issue in OMPT, including exact steps to cause it to crash on cue. No response yet. (surprise, surprise).
Anyway, hopefully all the trial/error in this post might help someone out there trying to use Play with OMPT some day. ;) Ceekayed, if your audio hardware is pretty decent, you should be able to get PLAY running as described above, being stand-alone and controlled via MIDI using the VST2MID plugin from 'midibag' in OMPT -- continuing my use in such configuration with virtually no looking back (except for the 'wonder if they'll ever fix it...?' thought every so often, I must admit..!)
QuoteOther day I posted a support ticket on soundsonline.com for the PLAY issue in OMPT, including exact steps to cause it to crash on cue. No response yet. (surprise, surprise).
I'll be very surprised if they take the time to look into it. The best case is you'll get a response saying, "I'm afraid we don't officially support OMPT".
But here's hoping.
Well, the crash is clearly happening in their DLL, so they should fix it, not us. If they don't look into it, they are just complete assholes making money from hard-to-use (because incompatible with apparently not just one host) and insanely protected software that noone should even bother to buy.
Quote from: Jojo on May 21, 2011, 11:19:10
Well, the crash is clearly happening in their DLL, so they should fix it, not us. If they don't look into it, they are just complete assholes making money from hard-to-use (because incompatible with apparently not just one host) and insanely protected software that noone should even bother to buy.
That's a truth right there if I've ever seen a one!
I'm also taking another approach to the problem, I can get my hands on the kontakt versions of SOG and RA, albeit a bit illegally. But I find no moral dilemma there, I feel it's my right to replace a broken piece of shit software with a working version of the same software.
Stormdrum I will continue to use sample-based, I think. Just gotta take the time to do some .itis out of them so they're a bit easier to handle. Luckily it's not Tonehammer stuff with 10+ round robins per sample (though it is a huge downside to SD2; making fast and massive percussion stuff takes tons of little tweaking to make it sound even somewhat organic). Actually I'd pick $400 worth of Tonehammer percussions over SD2 any day (that's a tip for anyone who's considering of getting some organic percussion instruments).
And nah, my hardware setup is back at ground level for a while as I have no working audio interface for the moment, thus I can only run a one instance of asio at a time (which is really driving me nuts, by the way!).
Kraz: I figured as much, just being hopeful in even submitting it in the first place, to be honest. And (as yet) have not had anyone even look at the ticket... But I do agree with Mojo (er.. Jojo.. lol) on this one; they should via (if anything other than 'the right thing to do'...) due dilligence fix or at least look into it. Besides, it's likely an easy code change and/or addition, too, if the problem has to do with the signal kill when switching patterns/orders that Jojo told me about.
=-=-=-=
Jojo: Don't say 'noone should buy' until you hear the guitar freaking OMG Awesome Les Paul patch I'm gonna use in my next song. Buying this thing (MR ie 'Ministry of Rock' component or as the CCC) is less than it'd be to pay him to play for you [edit: not to mention impossible, since he died a couple years ago... and I doubt the 'Les Paul Deluxe' lead patch was played by him, just was on his guitar. But hey, he invented the instrument anyway (amongst a whole bunch of other stuff over time!) and the patch is simply amazing! Sounds like I have someone like Steve Vai or Satriani playing along to my track..! And, for THAT, you'd need to spend more than $500 -- which I think would go without question... ;) -=- I'll post a short excerpt of the new song with the guitar solo featured, on my site later -- and add the link to this post then. I'm sure hearing it would at least improve oppinions of the MR library...! There's really a LOT of stuff in it that makes it more than worth the cost, to me and several major writers out there... I just think it's rediculous to have to spend a bunch of money on a DAW to use libraries like these (which is why I still use OMPT for all my composing) -- so, yeah. :)] -- so there's the worth in it right there, if you ask me. Now, as per the licensing, anti-pirate measures, overall stability and VST (compatibility) issues and overall shit-ness levels per the above, I DO wholeheartedly agree. I should NOT have had to spend all those HOURS banging my head on the wall only to come up with a workaround which will likely be branded a 'solution' due to EWQL's perceived lack of concern. :( But I did.. so I just hope someone can make use of the tips.. ;) And lastly: using it is EASY -- getting it running 'decently' (I don't consider outputting MIDI from a host to a stand-alone 'hog' of RAM to be much more than 'decent' or 'passable' though I at least have no real latencies .. unless I load a lot of stuff and try to hit play..) was SHIT. In my case, included the cost of another audio interface as well.. though my existing specs most definately met (even exceeded a little, IIRC) required specs from EWQL... <sigh>
BUT DAMN it sounds so nice :D :D :D :D
=-=-=-=-=
CK: DAMN dude, you need some audio gear! What happened to your old stuff?
I too will have to sample things like Symphonic Choirs and/or the aforementioned Les Paul patches and (waaay back up there..) the Bösendorfer and similarly FREAKING HUGE samples/instruments/combos.. making tracking a bit more of a challenge but nothing I hadn't already had to try doing for one reason or another.. so I'll survive (even if it takes longer to get a track done for now..). ;)
=-=-=-=
So here it is. ;) This is an entirely-tracked guitar solo using only the MR component from my CCC library, composed using OMPT 1.19.02.00.
You could comment here or on my site's guestbook if you'd like.. ;)
http://www.christofori.net/preview (http://www.christofori.net/preview)
I'm diggin' it.. kinda good for just starting on guitar, huh? (I have always wanted to take the time to learn it, just never have.. may not need to now, though! Don't need to purchase one and all the gear for it now, either...) :D
(For ppl reading a while from now: the link will be somewhat short-term as I update contents of that folder periodically... no guarantees as to how long after the date of this post the solo reference mix file will continue to exist there; but it will be there for likely a month or more at least.)
Official response from EWQL
=-=-=-=-=-=-=-=-=-=-=-=-=
Hello,
I am not sure what OpenMPT is but we don't support it as a host.
Here list of our supported hosts is here:
http://www.soundsonline.com/Terapack
Click on Tech Specs and scroll down to the bottom of the page.
Best
Kia Glover
=-=-=-=-=-=-=-=-=
My response back:
=-=-=-=-=-=-=-=-=
So you're taking the 'easy way out' so you don't have to look into the potential problem, huh? I thought you might. Oh well. It's a mark against EWQL in my book as well as for many other trackers like me -- as I've been keeping others informed as to the status/response on this issue... I imagine they won't be purchasing anything from you guys now. :(
I suppose I'll just muddle along with my workaround since you won't even try.
Thanks though.
=-=-=-=-=-=-=-=-=
So.. there you have it. There is no issue because they choose to ignore unofficial "unsupported" hosts.
Last 'tech' post for me here I think.. as my afore-mentioned 'workaround' now produces output with no latency issue. I had begun using 2 sound cards to further clutter up my already frakenstein-ish setup -- one (Focusrite) is for the output (generally) and the other (my old Delta 44) is to record 4 tracks simultaneously. In getting that to work (won't go into all I did, to spare the poor readers the extraneous detail) I did have to fine-tune the latency settings of my PCI bus (as the Delta and the firewire controller card [which hosts the Focusrite card..] are both connected to it) -- I did so with a program called simply 'PCI Latency Tool 3' available (currently) here: http://downloads.guru3d.com/download.php?det=951
Additionally I came across another tool which might help those with latency issues on their own PC's. It is a real-time graph that helps you determine if your PC might have latency issues with digital audio, called 'DPC Latency Checker' and is (currently) available here: http://www.thesycon.de/deu/latency_check.shtml
My appologies if these tools had already been mentioned elsewhere..! But -- hopefully now, this thread should contain enough information for anyone to get EWQL PLAY products running properly on their systems with OpenMPT (though not as a VSTi of course). It might also help some with latency issues, too. ;)
Quote from: christofori on May 27, 2011, 04:10:47
I am not sure what OpenMPT is
Awesome, they're even too stupid to read your mail (I am 100% sure I added a link to the
download page in the template I gave you)! Ok, I think we're done here - I guess this is good argument for anyone here to not buy any of their stuff anymore.
I'm not sure what EWQL PLAY is, but OpenMPT, as a host, does not support it either! :nuts:
True, true! :nuts:
Though, it's very well possible that you just got through to their "basic end-user" support. I suppose if you could get through to the programmers or at least somone who knows about the tech bits, you could probably get a more sophisticated answer (though that's what they generally try to prevent, of course).
Quote from: LPChip on May 27, 2011, 10:03:07
I'm not sure what EWQL PLAY is, but OpenMPT, as a host, does not support it either! :nuts:
LOL -- I'll keep that in mind as I continue running them in tandem via MIDI messages (a suggestion from an old post you made, if I'm not mistaken -- on another issue, having something to do with sending MIDI messages out from OMPT; so I owe you thanks as well!). Though it is very evident now with my multiple sound card drivers running; as when you even attempt to play (no pun intended..) a song containing PLAY, it crashes OMPT immediately. Wasn't quite that volatile prior to adding my Focusrite card. But, I've at least got something that works. :)
One last note (I keep saying that, lol) for any others that want to use PLAY: I had my PLAY percussion instruments (that is: instruments in OMPT set to send MIDI data to PLAY percussion patches) set to use a Note Off command under the NNA's -- doing so seemed to cause some lag/latency on said instruments. Setting them to "Continue" fixed that last minor problem. Seems the odd timings of the Note Off that OMPT sent (odd because it was immediately before a new note.. instead of on a beat or upbeat as per normal releases..) might've been causing too much MIDI data for my system to perform it all properly. It was driving me crazy because only in certain sections would there be any 'lag' -- and it was always consistant (which wouldn't be consistant with 'normal' latency as I understand it). But at any rate, my funky syncopated rhythms are playing fine now. :) You couldn't do this with sustained instruments obviously, but I would think notating the note off commands in the pattern data itself would be standard proceedure for most people there; but it's worth noting.
It bares noting publicly that after installing the latest PLAY 3 update (published Dec 8th 2011), I have yet to crash OMPT when using PLAY as a VST. This however is not something I have tested extensively, yet. Funny thing is, the samples seem to load faster in the VST version of PLAY than in the standalone version.. so I might try switching my composing of tracks back to the VST version and see how it goes.
I should also state that I'm currently using the latest testing version of OMPT as of the date of this posting (1.20.00.57) and PLAY is 3.0.30 and all virtual instruments I use are also patched to their latest/greatest versions.
It might be a bit soon to celebrate; but it makes me wonder...: why couldn't they have released PLAY 3 back in May..? Oh well..! :)
Good to hear. :)
Quote from: christofori on December 18, 2011, 03:50:17Funny thing is, the samples seem to load faster in the VST version of PLAY than in the standalone version.
If you did that comparison without an extended break between the two tests, this has probably not much to say because the samples would most likely still be placed in the disk cache then.
QuoteIt bares noting publicly that after installing the latest PLAY 3 update (published Dec 8th 2011), I have yet to crash OMPT when using PLAY as a VST. This however is not something I have tested extensively, yet.
Thanks for reporting. Please keep us posted if any problems crop up.
Quote from: KrazyKatz on December 18, 2011, 15:09:25
Thanks for reporting. Please keep us posted if any problems crop up.
The performance of the v3.0.30 PLAY VST in a song i'm currently composing (so far just using some drums and a LOT of the Bösendorfer 290 Master, a BIG sample set from Pianos Gold) is a bit laggy, causing some sound artifacts as some of the samples are loaded/reloaded. This doesn't occur when using PLAY as a stand-alone ap and interfacing to it as previously described some months ago (ie: using VST2MID to send MIDI data from the tracker to control the stand-alone iteration of PLAY). i attribute this to my using the Bösendorfer 290 samples (they, as mentioned some time ago, are 'friggin HUGE'). Also, i must note that if you keep the VST window OPEN while playback occurs, the performance is FAR better than if you close it and let it run 'in the background' for some reason.
HOWEVER, all that said -- still there have been 0 crashes.
Given the results, i'll likely still (for the time being) continue tracking with the stand-alone version of PLAY. Still, it's nice to see that they seem to have (finally) addressed the issue(s) causing incompatibility..!
Quote from: Jojo on December 18, 2011, 13:18:14
If you did that comparison without an extended break between the two tests, this has probably not much to say because the samples would most likely still be placed in the disk cache then.
My goodness, you think of everything, don't you? (That's why we love you!) :) You're quite correct... earlier loading the samples took just as long as normal. And this "earlier" of which I now 'speak,' was after a fresh boot of the system. Prior testing had been AFTER running PLAY in stand-alone mode... doubt there would have even been a minute or so even, between the time I closed stand-alone PLAY and opened VST PLAY. Good catch. :)
Quote from: christofori on December 19, 2011, 02:03:28My goodness, you think of everything, don't you?
If that was the case, there would be no regressions in every new OpenMPT version. ;D It was just a quite obvious pattern for me. :)
I don't believe play would work with OMPT with the way it's designed. I use play myself but don't have it right now as my computer that has the EastWest libraries on it is in another country from where I am.
Quote from: corlenbelspar on January 06, 2012, 13:18:41
I don't believe play would work with OMPT with the way it's designed.
And what is this magical way in which it (OpenMPT? PLAY?) is designed? As I understand PLAY is just a normal VSTi which should work more or less directly in any VST host (modulo unimplemented features or wrong assumpations made by the plugin or host authors).
I can't remember what I read that said it was designed weird but from what I remember the thing I read said it should only work when used in a program like Cubase or whatever.
They say that because they don't want to spend money on user support for "lesser" DAWs. PLAY may work just fine in many hosts they do not officially support, but you won't get any help from them if you use such a DAW and apparently they do not intend to fix their plugin for those programs, too.
I think that attitude from them is utter bullcrap. Module music is definitely a major music format and they're ruining it for themselves if they refuse to support it.
Well, I guess supporting more hosts means spending more money on development for them - and who knows how aged and bad their code is so that a rewrite of half the code is necessary to make it work with more hosts. But as reported by Chris above, things seem to have improved, so there's hope...