Hello folks -

MIR is on sale, which draws me to thoughts of another attempt at buying and using it.  One thing that's difficult about sussing the viability of any solution for one's workflow is being able to ascertain what kind of performance one might expect from it on one's particular system.  There are a lot of posts with statements like "using a modern computer, these settings will most often produce an acceptable result."  I understand that kind of answer - I do!  But it doesn't help too much, really.  So many variables there, including what's acceptable.  We all work differently to a degree - some more real-time than others, for example.  I use a lot of SWAM and SampleModeling instruments, and with my VSL libraries I do a lot of breath-controlled performance, so responsiveness is key.  Being under deadlines, I usually don't want to have to play something dry and then place it in the space after - once the part is in I need to move on, and in any event not hearing things as they will be is a cognitive as well as a working slow-down.

  So in the interest of a narrow but perhaps repeatable spec, I'm asking if anyone else is working with a system like this:  2013 12-Core Mac Pro, 128 GB RAM, Pro Tools (HDX) as sequencer, HD|IO as interface.  Nothing similar to that - that exactly.  A template in VEPro using many different libraries and instruments, not just VSL but Kontakt, SWAM etc. - lots and lots of stuff.  Maybe 40 sources to put into MIR.  And also let's assume that you use HDX plugins for realtime processing as much as possible (as the native round trip on an HDX system causes latency).  What I'm interested in is the following:  If your template requires a 512 or a 1024 buffer in PT, what kind of buffering are you needing to do in VEPro and MIR to get stutter-free playback on a full-orchestra piece, and what latency in live performance does it incur?  Have you found a relationship between raising the VEPRo buffer and being able to lower the MIR one?  and do you get better performance by using MIR in PT or in VEPro?

I'm thinking that it would be very useful in general if people who used other systems or other platforms also had a place to list configuration and performance specs on this site - is there one? - but I'm really just hoping to hear from people who use the same system I do.

Thanks!

Updated to 7.0.973 on main Mac Pro and satellite Mac Pro. Both on Mojave 10.14.6, with latest security update. Now when I launch the server plugin in Pro Tools, The plugin displays the local host twice (same address, same instances) but doesn't show the server on the other machine.  

Screen sharing works, so it isn't a cable.  Sharing enabled on both Macs. Firewall set to allow VePro, VEPro server.   

Thoughts?  I use the satellite in my template every day so this is kind of a thing.

Thanks!

 

EDIT: When I updated software my IP address changed for some reason.  reset, fixed.

As mentioned in a thread below.

Bumping this.  

2013 Mac Pro, 2.7 GHz 12-core, Mojave.  Latest VEPro.  Sequencing with PT or Cubase or Logic.  Also a 5,1 Mac Pro with 2 3.6 GHz 6-core, Mojave with VEPro.  

Now that my template is larger I've been obliged to think about processor allocation.  To be honest, before I didn't think about it much - it was set on both of them at 6 or 7 per instance.  I did most things within one or two instances, and sometimes I'd add things and realize I'd "allocated" more cores than I had, but everything still worked fine.

 Now things are laid out differently - typically a library, like Berlin Strings, or CSS, or the AudioModeling winds, in an instance.  This was initially done so that my library could be modular and I could only use what I wanted at the moment - but now I kind of need all of it.  Now, in the case of the SampleModeling Brass, for example, I have them split out as horns in an instance, trumpets in an instance and so on, because I've needed to be sure they have enough dedicated DSP to work reliably.  Same was true for AudioModeling Strings when I was using them built into an ensemble - things seemed to go better when I dedicated sections to instances.  

I'm not having trouble now per se - but If I add anything I likely will.  

So is there any current wisdom about processor allocation per instance?  Would I be truly better off with fewer instances but more outputs per instance? (One instance - my "rock band" one - has 24 output pairs, because it's Superior Drummer 3, Trillian, many Kontakt instruments and the Synchron Yamaha piano.)  

In short - I feel like I may be under-using my computing power in some ways and overusing in others.  Thoughts, anyone?

 

Thanks -

Richard

Mojave 10.14.5, latest VEPro (Catalina with the update, .922 I think), Peo Tools 19.6.0.370

When I open my rather large template in VEPro, it loads (takes ca. 5 minutes). It’s saved as decoupled and corresponds to the cue I’m working on. I Launch ProTools. Load the session I worked on all day yesterday without issue. As soon as ProTools gets through restoring everything and is building the overview file, VEPro quits.

Returns this in the crash report:

Crashed Thread: 757 at.co.vsl.viennaensemblepro.ProcessThread.2

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000001a8
Exception Note: EXC_CORPSE_NOTIFY

(Skipping down to the thread in question)

Thread 757 Crashed:: at.co.vsl.viennaensemblepro.ProcessThread.2
0 com.parallax-audio.Vss2 0x000000011dca3b6b AUBase::DoRender(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int, AudioBufferList&) + 1899
1 com.parallax-audio.Vss2 0x000000011dc998fe AUMethodRender(void*, unsigned int*, AudioTimeStamp const*, unsigned int, unsigned int, AudioBufferList*) + 46
2 at.co.vsl.viennaensemblepro 0x0000000110036dcb AUPlugin::process(long long, float**, float**, int, float*) + 763
3 at.co.vsl.viennaensemblepro 0x000000010fca177c AudioChannel::processFxRack(long long, int, float**&, float**&, int, float*) + 764
4 at.co.vsl.viennaensemblepro 0x000000010fca2b3d AudioChannel::process(long long, float**, int, float*) + 3181
5 at.co.vsl.viennaensemblepro 0x000000010fd0457a VIAudioEngine::ProcessThread::run() + 1178
6 at.co.vsl.viennaensemblepro 0x000000010fd2495e void* std::__1::__thread_proxy<><><std::__1::__thread_struct,></std::__1::__thread_struct,><std::__1::__thread_struct> >, void (VIAudioEngine::ProcessThread::*)(), VIAudioEngine::ProcessThread*> >(void*) + 62
7 libsystem_pthread.dylib 0x00007fff7c5152eb _pthread_body + 126
8 libsystem_pthread.dylib 0x00007fff7c518249 _pthread_start + 66
9 libsystem_pthread.dylib 0x00007fff7c51440d thread_start + 13

Took out my beloved VirtualSoundstage 2 and it works again.

So my question is - this happened all of a sudden, so has anyone else had a plug-in just spontaneously start killing VEPro? Or might it be a fragment of data or pref that VEPro sets in a plug-in that gets corrupted?

I rather miss VSS2 now - all of my AudioModeling winds were going through it. I’d found that MIR was a little heavy on the system and added too much latency to be a good fit, though I liked how it sounded. I’ve replaced VSS2 with an early-reflection program from an algo reverb and the show goes on, but... not insanely great.

Thanks.


</std::__1::__thread_struct>

I’m on Mojave. Running VEPro with Pro Tools 2019.6. Ten instances, probably 100GB of RAM usage. Also running it on a remote MacPro 5,1, also running Mojave. 8 instances, around 58 GB. Is there any reason I shouldn’t install the newest version? It appears to solve some issues I have been encountering.

Ten.  Soon to be more as I've rethought the way I'm using Berlin.

Hi folks -

So admittedly this template isn't tiny, but I'm wondering about this.  

On my main machine with the DAW (2013 Mac Pro, 12-Core), for the show I'm doing right now, I'm using these instruments:

• Berlin Strings (all articulations except multi's, all expansions)
• AudioModeling Strings
• CSS/CSSS
• AudioModeling Woodwinds
• Superior Drummer 3
• Trillian
• Vir2 Acou6tics (Nylon, Steel String, Ukulele)
• Indiginus Ukulele
• ISW Pedal Steel
• Omnisphere 2
• Serum
• ANA2
• 8Dio Lacrimosa Choir
• Strezov Muted Seiler piano or VSL Synchron Yamaha
• Orange Tree Evolution Texas Twang
• Soniccouture Pan Drum, Tingklik and Bass Tonguedrum
• Soundiron Anklung

This takes up 103GB of my 128 GB RAM, which makes sense.  My server project files are around 435MB typically.  Is that an appropriate size for them?  Seems big but I have no real point of reference.

Thanks.

I’m digging this post back up because I’m still having this problem. I never used to have to tell the VEPro plugin what the network address is and name of the instance is on either of the remote computers. It used to just appear under the local host as an option. This is with the latest version of VEPro 6. Wondering a few things: if this issue is a known thing, if it’s resolved in VEPro 7, and if my 5,1 12-Core Mac Pro slave computer running High Sierra is going to take a performance hit if I move to VEPro 7.

(I’m not running any new network software - nothing has changed there on any machine I use, though if I think about it, I have installed the latest security update to the OS. But though the firewall is on, the VEPro software is allowed, and is set on the slave computer to advertise its presence on the network.)

Paul, any thoughts?

Hello folks -

I'm looking to avoid bringing my slave 5,1 Mac Pro 12-Core up to Mojave spec by buying a Metal-capable video card - I don't even use a screen with it, as it's accessed via screen sharing - so I'm wondering if anyone is using Mojave on their main computer (in my case a 2013 Mac Pro) and High Sierra on a slave, and successfully using VEPro 7 on both.  Or is this just asking for trouble?

Both computers are on High Sierra currently.

I’m against improvement? Not so. I’m just unwilling to do it in a way that is only marginally better than what can already be done (in a cumbersome way, yes, as I have previously mentioned). I am for improvement, but we don’t think of it in the same way, that’s all. Good luck to you.

I see you really like the slots idea. Great. Just saying it’s nothing new, and too close to what you can already do to be compelling.

If that’s all you want, that’s cool. But is there some reason you wouldn’t want more functionality that didn’t involve, say, twenty slightly different MIDI processes in slots when it could be done more elegantly with a more object-oriented system?

A single-slot-only solution is extremely limited. Much more versatile if, rather than a single MIDI process addressing a single instrument, instruments were objects that could be addressed collectively if desired. There are already lots of ways to transpose, delay, arpeggiate and so on, and simply putting a plug-in before an instrument can be done in virtually every sequencer on the market. And I have done this kind of thing with Logic scripts, OrangeTree Mind Control, TransMIDIfier and just plain after-the-fact MIDI editing. What I’m describing here is something that is not being done in any plug-in host, or using any single solution, or in anything resembling an elegant way. But intelligent articulation time alignment is a basic need that’s not going away. Until it’s all modeled in real time, we will need to deal with samples that can think ahead. But while we are at it, there are other things we can do - if we change the metaphor from mixing board to network, we can do a lot more, in elegant and intuitive ways. Doesn’t mean you have to - but everyone doesn’t have to do it your way. If the system is flexible enough it should accommodate whatever metaphor the user wants. Maybe asking a lot of this software, but these are the people who built special rooms just to record orchestras in. They can make big moves to get big results.

Maybe a starting place for them would be using the model of the Vienna Instrument or Synchron player- except that each cell would actually be able to be pointed at any MIDI destination in VEPro.

Almost.  The issue is that when using a legato articulation, the first note is just like any sustain patch.  No delay required.  When an overlapping note is played, it triggers the legato transition, and it's this delay that must be addressed and compensated for.  So the script has to look for an overlap - a note-on before the previous note-on's note-off - and then do the script.  That's why it either has to be done in the sequencer, where the sequencer could read MIDI ahead, interpret articulations and overlap, and offset playback per note accordingly - OR... in a script in a host like VEPro, there's an overall delay to all notes, but for legato overlaps the delay is less.  So, say 1000ms for everything but if an overlap occurs the note-on delay is only 900ms if a fingered legato, 500ms if portamento, and so on.  So the offset for this script would be advancing 1000ms.  And this would obviously be a playback-only thing - useless and annoying for realtime performances, but great for output from Dorico or step entry or what have you.

And one wouldn't be able to do all the fun things I was describing before (and also enjoy life) if one had to put a script on every instrument.  It would be better to have a folder with all of your targets for a given combination patch inside it, or just the ability to target any instrument that's loaded in RAM in one of these combined patches.

Lots of these things can be done if you don't mind fifty steps.  It's just that we have these machines in front of us that can think like this all day long.  And I know I can figure out what average legato transition delays are - but I'd like it if the manufacturers would do that for me.  (One does.)

If that plugin included scripting that would be amazing.  I'd love to have legato offset scripts in there, though that might be done best in a sequencer host - not sure if a host could successfully report delay compensation to a sequencer, given the amount of time involved, on the order of hundreds of milliseconds as opposed to samples.  But I would settle for TransMIDIfier-style routing of incoming MIDI data.

Hi - getting ready to install VEPro 7, and just wishing (perhaps too soon) for a few things, prefaced of course by "maybe it's just me":

I would love the ability to put a bunch of instruments in a folder, and be able to put some MIDI rules out ahead of the folder, controllable by keyswitches or CC, that would allow me to create a single-channel (to the sequencer) meta-instrument for all of the combining and layering that I do, but with controller-, note-range-, velocity-range- and transposition-modifying for each instrument, and perhaps the transposition-modifying could be constrained by a scale, and maybe even one that follows a key change map.  So one could, for instance, use a string library's sections, spread out across whatever range one chooses, but on the keyswitch for short staccato, add in the VSL Chamber shorts as well, with their volume controllable separately, and at a high velocity on that articulation add in brass shorts from Metropolis Ark - and because this could be following the scale pattern you have entered in, on one or two fingers you could harmonize a line very rapidly.   

(I know one can do a lot of this already, but we don't all only use VSL libraries, do we? And wouldn't we rather program a host than program variations on a basic patch for twenty different instruments?)

The reason I suggest this is because it seems to me that hosts ought to do this kind of thing - facilitate combination of libraries and add flexibility to them by modifying what they do with MIDI data.  I don't know if that would make it impossible to render faster than realtime, but if it didn't then why not have these features?

Just thinking about it.

Pro Tools HDX, version 18.12.0.37, Synchron 1.1.1497, VEPro 6.0.17226. Mac OS 10.13.6. 12-Core nMP with 64 GB RAM, Samsung 970Pro SSD on a Lycom PCIe card for library.

So I was recently writing some trailery music and wanted to use the lovely Yamaha CFX. Immediately had weird dropouts - the CPU meter in the player matched them perfectly with peaks - and I noticed that on other attempts when using bits of the new Synchron Epic Orchestra in VEPro that I had the same dropouts, but that they were not metering in VEPro - only in ProTools. On further experimentation I found that the dropouts were vastly reduced or eliminated when ProTools was playing (transport running), but were not affected by changes in buffer sizes in ProTools, changing the number of cores allocated to the Synchron player or VEPro, or reducing the number of mic positions used. Subsequent tests in Logic Pro showed no problems playing any of the instruments whether in play or not and at much lower buffer sizes. This indicates to me that there is an issue in how PT handles these instruments. Thoughts?

Richard F.W. Davis

Wow - can I try it with VEP7 too? :D

As it turns out, it started showing the server address again - I tried manually entering it, but it didn’t work - but what did work was dropping the cursor in that field and waiting a moment - and then the local host appeared above it and the server address appeared on its own. Some kind of appearance bug maybe. Anyway, back to work.

OS X 10.13.6, VEPro 6.012766, PT2018, Logic Pro 10.4.4, Cubase 9.5, eLicencer control 6.11.6.1247.

After a recent hellscape while trying to audition MIR fraught with sysopos and other errors, I finally got through that by updating from an elicenser I'd been using since 2006.  (13 years of dragging a piece of plastic around the world is not bad at all, really.)  Now VEPro launches without a problem.  Yay!  Except now, every time I launch the plugin in any application, and have the server app going, the plugin can't see any server instances available - not even to make a new one.  And then when I try to quit the audio app that's hosting VEPro, it crashes, no matter which one it is.  I have uninstalled and reinstalled all the VSL apps, to no effect.

Any thoughts, anyone?  This is running VEPro on the same machine.

Hello folks -

Runnng Cubase 9.5 and the most recent update of VEPro. The remote computer is a 12-core Mac 5,1. Both it and the 6,1 master Mac are running High Sierra .6. Buffer size in the plugin is 2. Sound hardware for this experiment is an Apollo twin duo. Using screen sharing to control the remote Mac.

I have a template of SWAM strings on the slave, duplicating the sections in an orchestra (for example, the violins I is made of 8 SWAM violins with placement and delays). I’ve used this same template with Pro Tools controlling it.

When I was setting Cubase up to push it, I made my MIDI tracks that were pointed at the ensemble plugin on the master computer, then connected the plugin instance to its target on the network. Loaded Violin I no problem. Then went to connect Violin II, and that worked. When I attempted to connect Viola, I got a lovely loud buffer buzz, and the connection worked for a moment, but then VEPro crashed. Since then I have not been able to get more than one instance connected without VEPro quitting.

Anyone else run into this?

 

It says it does.  You have to use a script that talks to matrices.  Haven't updated yet.

Your first problem could be a heat-related RAM issue.

You could use a utility to see (when it's reporting less RAM than you have) how big it thinks the RAM sticks are in each slot. Failing that you could pull all but one chip and wait to see if it fails, and go through this process with each chip. You didn't say the size of your chips - is it three 8's or 6 4's?

Hi folks -

The other day I decided to try MIDIOverLAN to enhance my rig a bit.  The goal is to sequence with all articulations of Hollywood Strings or Brass for a given section on one track, controlling articulation selection with keyswitches using TransMIDIfier.  Since I have PLAY instruments quarantined on a slave machine due to their almost hilarious memory allocation scheme, the idea is that I could send a single track output from ProTools 12 to MIDIOverLAN and have that feed TransMIDIfier on the slave machine, which uses keyswitches or program changes to reroute the incoming MIDI to internal MIDIOverLAN ports that push External MIDI ins on VEPro and thus the PLAY libraries hosted therein.

I know External MIDI is a sort of "experimental" thing with VEPro, but I'm wondering if there is any information about how much worse the MIDI latency is when using external MIDI than when using the internal VEPro network MIDI.  

I've always gotten great results from VEPro's embedded MIDI and am only using externals out of necessity.  Using externals means that there's no offline bounce, which is a major drag (though not anyone's fault, of course, that's just how things work).  See my earlier post regarding expanding VEPro Functionality about a potential future way around all of this nonsense.  In any event, were I able to use MIDIOverLAN in a sufficiently low-latency mode it would allow me to build massive patches spanning multiple machines (for instance, I have huge one- and two-fingered patches that layer string, brass or wind sections, but would like to build meta-patches that control all sections on different slave computers simultaneously).

 

Thanks -

Richard

Hi Paul - 

I'm glad you're hearing this.  I realize that I'm essentially asking you to upgrade everyone else's libraries' functionality, and that's a little odd.  But I think that a top-of-the-line host should have more transforming hosting features, and I can't imagine what I'd be doing without VEPro.  Surely cobbling things together with spit and chewing gum.  

What if the instrument matrix simply had hosted instruments as targets as well?  Such that the patch browser also listed available VI's and MIDI channels, and in the Channels column of the main display each channel would have the option of setting a VIPro as a MIDI source?  Not much of an interface change, no internal windows of third-party GUI's or anything.

Just thinking.