strange days...

s0c9

s0c9

Moderator
Moderator
Using the Editor to modify a patch I had built last night, so had retrieved it from the location to which I had saved it, as I wasn't happy with the end result and wanted to tweak it some.

Kept it simple per wiki recommendations.
Comp-> Amp-> Cab -> Reverb.
Comp added last.
Ended up with a nice clean, warm, bluesy patch.
Saved to the current location.

Played the saved patch (did nothing after the save. No recall, audition, retrieve, nada).
The warmth was gone. The patch sounded hollow and tinny and trebly/chorus-ey.
I checked settings in the patch and they looked like I remembered them to be.
But this was DEFINITELY NOT sounding like the patch I had just saved.

I then tried recall from Buffer.. same result !
Recall last saved version.. same !
Switched to another patch then back. Same !!!!!! <grrr>

Has anyone seen this occur before ??
Should I not be creating patches via the editor ? :?
Does what I hear when "tweaking" not occur in the buffer and get written to the Ultra when I click save (or choose a new location) ?? -- I'm monitoring the changes via OUTPUT 1 to my mixer..
Shouldn't that patch still exist in the edit buffer and mirror what was just written to the Axe-Fx ???
Am I missing something here ???

This is more than a little frustrating. I'm hoping this is some stupid user error. <wouldn't be my first>
Help please,

TIA
Steve
 
Which MIDI device are you using? Actually, I have come across the same. I was trying a MIDISport 2x2 Anniversary edition from Guitar center and it would "gobble" up changes and throw them all at once. I cant explain it, but I'd be making changes, and everything would be going along just fine and one change to an effect (doesnt matter which one) will throw everything off and the patch would sound thin, horrible and just plain un-usable.

Ever since I returned that one and got a Used MIdisport 2x2 from eBay, no such occurrences have I observed.

IMO, either try a different MIDI device or try messing with the buffer speed and see if the problem goes away.
 
I've had the same thing happen. Quite often the computer will throw MIDI information at the Axe faster than the Axe can deal with it. You have to remember MIDI is a fairly antiquated information transfer protocol, having been developed in the early eighties, and the speed of modern devices is far quicker than was ever envisaged then.

I've found a good general fix to all sorts of MIDI problems is to change the transfer settings in the editor. From the 'settings' menu, select 'editor settings'.

Try reducing the MIDI buffer size to 128 (this effectively reduces the amount of data transferred at any given moment) and try increasing the MIDI buffer delay to around 150ms (this effectively slows down the rate of transfer of data).

These changes will slow down the rate of transfer of MIDI data - to a degree which may prove too slow for you. You have to wait for the editor to send any changes you make to the Axe, which may be seen in the top left corner of the editor GUI - it displays 'Checksum OK' when the change has been transmitted. This can be frustrating when you're altering controls very subtly.

If it's too slow for you, gradually decrease the MIDI buffer delay time. I've got mine down to 63ms with no problems, but if I go any lower, I start to have data transfer failures.

I can't guarantee this answer will work for everyone, as there are so many different MIDI interfaces available, but it's certainly worth a try.
 
s0c9 said:
Using the Editor to modify a patch I had built last night, so had retrieved it from the location to which I had saved it, as I wasn't happy with the end result and wanted to tweak it some.

Kept it simple per wiki recommendations.
Comp-> Amp-> Cab -> Reverb.
Comp added last.
Ended up with a nice clean, warm, bluesy patch.
Saved to the current location.

Played the saved patch (did nothing after the save. No recall, audition, retrieve, nada).
The warmth was gone. The patch sounded hollow and tinny and trebly/chorus-ey.
I checked settings in the patch and they looked like I remembered them to be.
But this was DEFINITELY NOT sounding like the patch I had just saved.

I then tried recall from Buffer.. same result !
Recall last saved version.. same !
Switched to another patch then back. Same !!!!!! <grrr>

Has anyone seen this occur before ??
Should I not be creating patches via the editor ? :?
Does what I hear when "tweaking" not occur in the buffer and get written to the Ultra when I click save (or choose a new location) ?? -- I'm monitoring the changes via OUTPUT 1 to my mixer..
Shouldn't that patch still exist in the edit buffer and mirror what was just written to the Axe-Fx ???
Am I missing something here ???

This is more than a little frustrating. I'm hoping this is some stupid user error. <wouldn't be my first>
Help please,

TIA
Steve
Click to expand...

It may be a bug in the editor, it is still in beta. If you can recreate it, post it in the bugs sections of the software editor forum. You can always save a patch from the axe-fx itself and bypass the editor. What you hear coming out of the speakers is the buffer. The buffer is on the axe-fx not in the editor. If you post the patch we could take a look at it.
 
jonPhillips said:
I've had the same thing happen. Quite often the computer will throw MIDI information at the Axe faster than the Axe can deal with it. You have to remember MIDI is a fairly antiquated information transfer protocol, having been developed in the early eighties, and the speed of modern devices is far quicker than was ever envisaged then.

I've found a good general fix to all sorts of MIDI problems is to change the transfer settings in the editor. From the 'settings' menu, select 'editor settings'.

Try reducing the MIDI buffer size to 128 (this effectively reduces the amount of data transferred at any given moment) and try increasing the MIDI buffer delay to around 150ms (this effectively slows down the rate of transfer of data).

These changes will slow down the rate of transfer of MIDI data - to a degree which may prove too slow for you. You have to wait for the editor to send any changes you make to the Axe, which may be seen in the top left corner of the editor GUI - it displays 'Checksum OK' when the change has been transmitted. This can be frustrating when you're altering controls very subtly.

If it's too slow for you, gradually decrease the MIDI buffer delay time. I've got mine down to 63ms with no problems, but if I go any lower, I start to have data transfer failures.

I can't guarantee this answer will work for everyone, as there are so many different MIDI interfaces available, but it's certainly worth a try.
Click to expand...

Jon,
Thanks, hadn't thought about this aspect. Haven't had a single checksum error on anything I've done in the editor thus far so had not considered midi xfer to be a factor.
That includes using the tuner, backups, auditioning/editing patches both from the Axe, banks, preset manager or even single .syx loads. I've hit the editor pretty hard since I started looking at it a few months ago. Started using it [for real] last week when I got my Ultra.
Speed has not really been an issue either. There is a noticeable delay when loading patches from the Ultra, but nothing that I would consider bad, unmanageable or unacceptable. Plus, based on what I read in the forum "sticky" on interfaces, I had initially set the midi buffer to 256 and delay to 90ms on the editor before I did anything with the Ultra, so until this came up.. was really happy with the whole thing.

Will try adjusting those values at home tonight and see if I see any different behavior.

FWIW - I'm an Axe-FX Ultra noobie, but a career IT techie (developer, architect, product manager), and been using midi for many years.
 
javajunkie said:
It may be a bug in the editor, it is still in beta. If you can recreate it, post it in the bugs sections of the software editor forum. You can always save a patch from the axe-fx itself and bypass the editor. What you hear coming out of the speakers is the buffer. The buffer is on the axe-fx not in the editor. If you post the patch we could take a look at it.
Click to expand...
Not sure its a bug.. and have no data (at his point) to support it being one :)
Will see what evidence I can collect tonight when I try to reproduce the problem.

FWIW - I had mentioned in another thread about this same thing happening [patch sounding different], but had put it down to ear fatigue as I'd been playing for about 3 hrs straight when that occurred. However, when I had gone back to that patch it "reverted" to how I expected it to sound.
 
s0c9 said:
FWIW - I'm an Axe-FX Ultra noobie, but a career IT techie (developer, architect, product manager), and been using midi for many years.
Click to expand...

DOH! You probably know far more about MIDI than me then :D

Let me know how you get on...
 
jonPhillips said:
s0c9 said:
FWIW - I'm an Axe-FX Ultra noobie, but a career IT techie (developer, architect, product manager), and been using midi for many years.
Click to expand...

DOH! You probably know far more about MIDI than me then :D

Let me know how you get on...
Click to expand...

np.. I did not disclose that in my OP :D
Will post results/outcomes back here...
 
Quick update:
Tried a number of different midi buffer sizes in the Editor from 128 to 256.
Left the delay at 90ms.
Was not able to generate any sync errors. At 128 backups and sync from hardware were a little slower than the 256 size - but then all that data is inbound, not Ultra-bound !
[update] Reset buffer to 256 and re-ran. Backup goes much faster !!!

Set buffer size backto 128 and delay at 90ms

Edited and saved the patch mentioned in the OP. Saved it to the next slot up.
Retrieved.. Sounded same as the version i had just saved.. Recalled the original. It sounded as it had been saved.
Created and tweaked a new patch. Saved it to the next slot above the prior two and retrieved. It sounded as I had expected.

In summary - while I have no concrete evidence - other than not being able to reproduce the events described in the OP - it would appear that Jon's suggestion of reducing the midi buffer size from 256 to 128, cured my prior issue, as I was unable to duplicate it at at the 128 buffer size.
NOTE: I did not try to replicate the problem with the buffer size at 256. Will try that Fri night.
 
You must log in or register to reply here.
Back
Top Bottom