Any EWQL PLAY users?

[Christofori]

...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)

[Saga Musix]

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...

[Christofori]

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.

[Christofori]

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...! >

[Saga Musix]

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... :\

[Christofori]

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.    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.

[Saga Musix]

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"...

[Christofori]

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.

[Saga Musix]

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...!

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 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.

[Christofori]

[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.)    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).

[Christofori]

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?)

[Saga Musix]

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.

[Christofori]

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.

[Christofori]

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?

[Saga Musix]

* 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.