[mrp123Participant]

Don’t use apt-get. It can’t help you to install Editor.

But of course, use apt-get, or what other means you prefer, to install Java first.

The installation file you download from Allen & Heath is an automated installer, equivalent to a Windows .exe.

To run the installer, you likely will have to change the file’s permissions.

Right click on the file, and under properties tick the “allow execute file as program” box.

Then you can (I’m pretty sure) double-click the file to initiate the installation wizard. This will install Editor in a Windows-like way.

It can create a shortcut on the desktop to launch Editor as a finishing touch.

If this method doesn’t work, there are other more certain ways to make the installer work by typing commands in the terminal. I didn’t include them to avoid further confusion.

Good luck.

As an aside, I’m grateful that A&H unofficially supported Linux when most other manufacturers can’t be bothered whatsoever with Linux. So thank you, A&H.

[mrp123Participant]

^ this.
+1

Direct Out Option, Follow Mute not respecting the state of a DCA mute is a problem for us too. It forces us to avoid relying on DCA mute to mute inputs. We can’t afford the workaround of consuming mix buses so we can mute direct outs. Is this an option that can be built it?

Sorry for the off topic comment, but I couldn’t resist.

[mrp123Participant]

Larry,

I also had occasions with a second operator working with me on one mixack where we both needed PAFL. I did similar to what mervaka suggested, which is what one of you two will have to do. It’s messy. I don’t know what capabilities Planet controller have since I’ve not used them. If it’s too messy to support, you’d have to buy another mixrack with a Port B option card of your choosing, plus optionally, a surface, all to gain another PAFL bus.

Read on if you are interested in what I tried, if it may help.

Unlike you, our other operator had to use Editor software. I used a the T112 surface. We decided the best way for us with all the particulars we faced was that he have exclusive use of the PAFL bus. I created my makeshift PAFL bus by (first) using a spare stereo aux bus. It could be mono if you prefer.

By default, no input sources were assigned to the aux bus. However, all input source faders for that aux were set to 0 dB and were pre-fader send. To PAFL a source, I would assign the source to my aux bus and, of course, de-assign it when done, and temporarily set to post-fader send as required. If this amount of PFL were all you required, you could patch that aux bus to a physical output of the iLive to feed a headphone amp. But that’s not what I did.

I also needed to PAFL my legit aux buses and master bus, which were my respective monitor mixes and house mix. To do so, I reserved a spare stereo matrix bus. To PAFL my monitors or house mix, I would assign and de-assign those specific bus outputs to my “fake PAFL” matrix bus, in the same manner I would PAFL sources using the aux bus. At all times, my “fake PAFL” aux bus was assigned to feed my “fake PAFL” matrix bus, with the stereo aux fader output set to 0 dB.

My “fake PAFL” matrix output was patched to a physical iLive output that fed my headphone amp.

This process could have been simplified if A&H honored this forum’s feature request to route input sources directly to a matrix bus. That feature was voted down because it’s too unusual, and understandably so. This means you are forced to rely upon both an aux bus and matrix bus if your “fake PAFL” needs access to basically everything.

You are permitted to assign mix subgroups to an aux or a matrix, so either routing method would let you PAFL a mix subgroup. However, I can’t recall how those pre/post-fader settings behave. This was the only way I figure out.

As you may imagine, it made PAFL much slower, forced me to really concentrate, and think through my surface layout. But I knew that in our situation, I could perform all these steps faster, more reliably and safer using the surface as compared to the other guy using Editor. I just needed to practice.

I should also point out that this “fake PAFL” does not let you PFL anything at intermediate points within a processing chain (pre-compressor, post-eq, for example), or PFL’ing within the iLive FX rack. But I could deal that in my situation.

Lastly, if you are using any legit matrix buses and both operators need to PAFL them, then you’re out of luck. Maybe feed your legit matrix buses to some 3rd-party hardware for your headphones, like a selector switch, to PAFL at will. You’d have to get creative.

For me, these two-operator occasions were rare but necessary, so I didn’t let it bother me. If this were frequent, I’d definitely buy additional hardware for the other guy and create a better workflow for both of us.

Good luck to you.

[mrp123Participant]

My $0.02 regarding the capabilities of iLive: I asked an A&H sales rep at a trade show to explain why new software features were appearing in GLD with all the hype while iLive was clearly already stagnating (this was prior to the Qu). He tried to assure me that iLive has more power and capability in the MixRack than a GLD, and that iLive will always be a superior product by comparison because iLive is aimed at the professional market. He refused to answer why then these new features were continually absent from iLive. So, choose what you wish to believe.

I believe this all reduces to A&H’s evaluations and predictions for product line profitability, and less to do with equipment capability or obsolescence. I’m quick to believe that A&H has been netting more short-term profits by selling GLD and Qu compared to iLive, which is reflected by their product development. Even if they sell hypothesized iLive2 widgets with new features, only time will tell if this story will repeat itself.

Speaking for myself, I’d pay for an iLive update and/or upgrade to support my current investment. I recognize that the development of new features costs something regardless if they’re given to customers for free. In the past, specific iLive hardware upgrades were available at a cost to meet software updates. But I fear A&H won’t do this in the future. However, I have absolutely nothing to base my comments on except my observations of A&H’s behavior.

[mrp123Participant]

Thank you, A&H, for doing this.

In all humility, I suggest that A&H not end this promotion. I do not want to sound ungrateful, but from my perspective, this promotion is the most significant activity from A&H for their iLive products in 15 months since the last firmware update, unlike Qu and GLD. A&H’s recent behavior shows they are focusing most or all of their development efforts on the Qu and GLD product lines.

If this pattern were to continue and A&H were to resume charging a steep premium for an app that controls their aging, lesser supported, still flagship product line, whilst A&H is giving the equivalent app for free to the more supported yet lower-tiered product lines, I fear A&H will continue to alienate their iLive users. Even if charging for the app were helping A&H to prolong iLive development, we have seen no new activity for iLive by comparison like back-porting new features, bug fixes or address incomplete current features, which causes me and others to respectfully question its efficacy. I acknowledge that the question of how to extend product development requires a deeper conversation than this.

If I am in error, I apologize in advance.

[mrp123Participant]

+1

Please build in remote configuration of ME mixers. It just makes sense for robust usability and capability. I’d be satisfied if the remote configuration were performed using a separate computer; not necessarily from within the mixer. The ME hub has partial capability to this end, does it not?

I suggested the same idea of remote configuration to an Allen & Heath sales rep (who I will leave unnamed) when he shared with me at a trade show in Sept, 2012, the development of the ME product, prior to it’s official announcement. He dismissed my suggestion on the spot and replied, “If a FOH or monitor engineer ever finds a need to configure the ME mixer remotely, then the talent shouldn’t be using the product and should just stick to wedges. The talent should configure the ME mixer themselves.” (Not verbatim, but this all that he expressed.)

I’m still not sure if he was representing A&H by those comment, or that was his personal opinion. Anyway, it encourages me that other people see the same need.

[mrp123Participant]

+1 for Dual mix rack setup in offline mode

[mrp123Participant]

+1

Agreed, agreed, agreed.

Dear A&H,
Opening up only a subset of the control functions to the MIDI and TCP/IP protocols to date is disappointing, and hinders the creativity of your users. I’ve long envisioned doing more with my iLive if only I had access to more controls over MIDI. Others have ideas too. Please open up full control to MIDI / TCP/IP. Considering Editor has the very remote control capabilities that were looking, for albeit in a closed environment, can you please go the distance and allow 3rd party access to these same controls to satisfy our unique applications?

[mrp123Participant]

quote:

---

Originally posted by arsound

quote:

---

Originally posted by pngaudioguy

Just got back from my first gig using the mixpad app to run FOH for a big band.
Summary: Unusable.

---

I felt much the same way as you last year and expressed myself quite strongly on this forum. A&H came out with a fix a couple of months later, and I’ve had no problems whatsoever since then. I’m happy to share whatever configuration information might help, either here on through a private message.

Suffice it to say, I’m extremely pleased with MixPad now, as opposed to last year. I hope to use it for years to come and hope that A&H can help you like they did me.

---

arsound, I’ll take you up on that offer, too. I’m also interested in the iPad workflow, but frankly I’m throughly spooked to go through with it. I remember the early stories from people of dropouts that at the time even A&H couldn’t even quite figure out, then those that used ipad1 were solid and ipad3 were a disaster with dropouts, etc., and I don’t have time to trawl through those threads (especially all for a $100 app. I totally feel the same frustration.) Anyway, enough of my rant. Any help is appreciated. You can private message me or point to relevant forum posts and details, for myself and others for posterity. Thanks.

[mrp123Participant]

quote:

---

Originally posted by pngaudioguy

I believe the Linux version lags a bit behind Win and Mac. I’ve installed virtualbox with a Windows install, and the iLive editor v1.9 for Windows seems to run just fine in that.

I looked into the native Linux editor, and since it’s Live mode only, doesn’t allow for preconfiguring inputs, etc before a show. Just a thought.

---

I agree with your points. But I don’t recall the Linux release lagging *this* much. I hoped this all would’ve been sorted out by now, especially if the Linux version was mentioned in the Readme way back when.
I too have run Editor in Windows within a virtual machine without issues, so I have no question it works. My immediate problem is Linux does what I need in my application, and I’d have to go out of my way to buy yet another Windows license to run it in a virtual machine just to run Editor. I can deal with the lack of offline configuration, and that Editor is provided as-is without support and so forth for Linux. I run dual mix racks, so the offline point is moot. I just was hoping to continue my Linux workflow from firmware version 1.83, as it’s only recent that I updated my iLive firmware to 1.9.

Allen & Heath, any reply on this?

[mrp123Participant]

Bump.

I agree with the original poster. A&H is not serving the Linux flavor of iLive Editor version 1.90 in their software downloads area. At present, A&H is only providing Editor version 1.90 for Windows and Mac, and I’d like Linux according to the A&H Readme file, please. The URL Wouter provided is pointing to Editor version 1.83.

I manually created an URL just to see if I could make this work on my own, as follows: https://www.allen-heath.com/UK/Downloads/Pages/SoftwareDownloads.aspx?FileName=iLive_Editor_V1.90-Linux-x86-Install This URL is a blend of the current URLs that serve the Editor installation files blended with the package naming convention A&H used in their previous Linux Editor versions. However, this URL returns an HTML file of 55,014 bytes that contains the line:
<form name=”aspnetForm” method=”post” action=”SoftwareDownloads.aspx?FileName=iLive+Editor+V1.90-Linux-x86-Install” onsubmit=”javascript:return WebForm_OnSubmit();” id=”aspnetForm”>

I even tried incorporating the plus signs in my URL as listed above, and still no Linux package is delivered.
I need help. Thanks in advance.

[mrp123Participant]

I agree with Lieven. I also was confused by this apparent “problem”. My routing is different, but my confusion was the same. I’m using firmware 1.70.

I apply limiting to an aux bus. That aux feeds remote speakers that are inaccessible to me (don’t ask why…). I can only hear the signal fed to those speakers using PAFL. However, I never could hear via PAFL the limiting on that aux though the surface showed heavy limiting. I became more concerned when I routed this aux to a matrix and I still couldn’t hear limiting anywhere on that matrix though the aux showed heavy limiting.

This situation results in a “trick” the user must remember. The user must remember they either cannot use a limiter within routing though it appears to be available, or cannot trust their ears to set limiting without somehow monitoring the analog output directly, which may or may not be practical, or remember the only way to PAFL the limited signal is to hold the SEL button within the limiting section. Without this foreknowledge, the user will be disappointed or sorely surprised because they believe they’re applying limiting and discover they’re really not, or conversely be frustrated because they cannot hear the effects of limiting though the surface is clearly announcing otherwise.

A&H, can you somehow make it more apparent so the user may understand the limiter’s functionality, by way of the touchscreen and Editor for example?

[mrp123Participant]

When you enable “Filter Multicast” in your Linksys router, you are telling your router to remove, or “filter out” multicast traffic. What I don’t know specifically for your Linksys router’s firmware is if “Filter Multicast” affects just the wifi, or just the LAN ports, or both wifi and LAN. You’ll have to find this out. My -guess- is the filter is just for wifi. Hope this helps.

[mrp123Participant]

I agree that tar is a good, safe choice given your dilemma and caters well to the Linux users.
It only adds the extra step for the user to untar the file first, which technically ought not be a problem for the user.
As a courtesy, you could include a readme in the tar with tips for installation. For example, tips from your
Linux thread or whatever.

As for what I prefer, I work in Linux and Windows, which helped the times I encountered zip files that don’t open well except in Windows (I don’t recall why, but it was explained to me at the time).
And many Linux users avoid Windows, so…I’d say you’ve found your answer.

And thank you for your quick answer.

[mrp123Participant]

I can’t download the Editor for Linux V1.71. I get an Error 404 – File or directory not found – when I follow your hyperlink. Is this a problem with your website or do we have to wait for a release of the Linux software?

[Author]

Posts