…..

I think you are making assumptions and don't understand the architecture of the Axe-FX
hey! there's good insight there man!, particularly the idea that blocks can multitask - ie: I have a pitch block at beginning of chain that does whammy / dive / drop / octave, 1 phaser block to do vibe and phaser... Also, the use of modifiers on amp parameters can yield a single amp block channel that covers clean, edge, light gain, moderate gain, hi-gain and with varying tonal characters. This is avaiable within the Axefx's architecture - take a look!
 
I want to begin by saying I think "setlists" is an awesome new feature I look forward to utilizing.

While "songs" seems to be a solution to the problems encountered primarily in the II, not the III.

Let me explain:

Back in the II days, I had to set up my banks as groups of five, in sequential order, to create what were effectively five scenes per song.

The problem was latency; when can I change presets and await the full loading of such without it being noticed?

"Songs" appears to just be creating an easier path to that same workaround I was previously using, including its inherent latency problem. The original sales pitch of the III was, scenes and channels will eliminate most of the latency many of us experienced while using the II.

I understand from a laziness factor how "songs" is desirable, grab scenes from various presets and BOOM you are off and running. No need to build a preset from scratch and copy blocks from one to another.

I believe there are two factors at play.

1. Casual users do not understand that many blocks have features beyond their stated purpose, such as: modulation available in the delays, or delays in the pitch block, etc. As a result, they maybe near their maximum CPU having unnecessary redundancies within their presets.

2. It can be hard to conceptualize how to effectively collapse several complicated presets into one, I went from a hundred in the II to twenty in the III. I was forced to make decisions based on CPU as to where I was going to give up some features to fit within a preset. Those limitations are far fewer now due to the additional features described in #1.

With the excess CPU capacity of the Turbo, I'd hope additional scenes and channels from the current amount would allow for the same end result, with less latency, as everything would be pre-loaded within a preset. Also, the ability to grab blocks from other presets as we could in the II would also go a long way to simply the III's preset build process. Block library is great, but more complicated in practice. The loss of that feature was a major step backwards IMO.

What do you think?
Use the block library, problem solved. Or just copy and paste from other presets.
 
How was copying a block from another preset via the front panel on the II any easier or better than copying a block from another preset via Axe Edit on the III? Just takes a few mouse clicks. Choose the source preset, right-click the block you want and select copy. Change to the destination preset, right-click the grid spot where you want it to go and select paste. That's it.
 
when can I change presets and await the full loading of such without it being noticed?
"Songs" appears to just be creating an easier path to that same workaround I was previously using, including its inherent latency problem. The original sales pitch of the III was, scenes and channels will eliminate most of the latency many of us experienced while using the II.

Hi Luke,

Thanks for your thoughtful comments.

In fact, the scenario you outline is just one of the many applications for Setlists/Songs. In my experience supporting pro and touring players, the main application will simply be answer the age old call" "Don't Make Me Think!" -- The new list gets the right presets and or scenes in the right order, which typically changes from night to night. There are then sub groups, but all of these different categories of player will benefit from the ease of a Setlist that's easy to re-order, with easy to read names displayed for reference. In fact, there are also other benefits based on which of three main approaches a given player uses:

1. Approach 1: Change across multiple presets inside of a song. Despite all of the attention given to the seamless switching that scenes allow, changing presets is still the most common approach used by pros. The "gap" some people call "latency" turns out to be not so objectionable to these players or their audiences, especially once they're in a band mix at stage level. (I still love to obsess over perfection, but I've actually been slapped down on this by some serious names!) An extra benefit of Setlist/Song mode in this scenario is allowing the player to switch directly to ANY scene in a target preset rather than just the default scene. The new system also allows them to make easy substitutions, for example, editing a "Global Lead" that is shared by all songs. Of course, the main benefit is almost no tap dancing between songs.

2. Approach 2: Use one preset per song. These players may or may not tap dance on effects like Boost or Delay, and may or may not change scenes. This is the second most common approach and is used not only by the "all in" modeling users but also by those who use the Axe-Fx alongside a tube amp. This group enjoys all of the advantages above — especially having things instantly in the right order — but can also enjoy having a trimmed down set of selections on the floor without needing to look past the scenes needed for the current song, and without ever needing to go to a Bank/Preset layout.

3. Use just a few presets -- for the whole show. Even the Kitchen Sink preset user can get good mileage out of Setlists/Songs. Like the middle group, these people benefit from having a structured set list to arrange scenes in order across 32*6 = 192 sections for a show. Imagine the flexibility gained by trading in eight scene footswitches for six effects alongside section +1 and -1 switches. Or, in a totally different use case, imagine using the six sections of one song all night (Hi Dweezil) -- but then employing a single tap to display six alternate "icing on the cake" presets for creative decoration.

PS: In reference to your comment about the Turbo, I'll mention that the extra DSP power of the Axe-Fx III Turbo allows creating more intricate presets with a greater range of possibilities from a single sound, but has nothing to do with the ability to add a greater number of scenes or channels. That change would require a massive system-wide re-architecture and additional preset memory, but not more power.

PPS: You mention Block Library as a way to move blocks between presets. I trust you also know that you can simply COPY and PASTE from one preset to another :)
 
I have finally sat down to play with the new setlist/songlist function and here is what I have found so far!

1. I have found that I can get the bulk work done of importing songs by editing the XML file that you get when you export, and then importing it back in. I usually use Notepad++ for complex Search & Replace, but considering these were pretty easy, it can be done in almost any text editor that has S&R capabilities and I used Dreamweaver. I was able to do search and replace on the Section Names, preset number, scene number etc., which gave me a fully populated list of 128 songs which had my default preset and scenes therein, inserted. I have about a dozen songs that I will have different presets for, but the other 40+ songs all use one preset and its various scenes (with an occasional effect thrown in), so rather than putting each song in and then clicking on each song section for preset, scene and name of section, I was able to get them all populated in a minute or two by searching and replacing in the XML and then importing it to Axe! I will most likely write some script or a spreadsheet macro to automate this process down the road a bit, so that I can take my list of songs in a spreadsheet when modified and output a XML file with this formatting and structure to import into the Axe FX. Would be great if I could just throw a CSV or XLS with structured columns and rows and the Axe Edit pulls it in to proper setlist/songlist fields, but that is not here now so a workaround will have to be implemented for easing this import/export/modification process.

2. The P# in the "Song Sections" area and the S# are not in sync (P# is zero based in machine, but 1 based in the XML, S# is 1 based in both machine and XML). So in the XML (that you get from exporting a song list) I have the following structure for a song:

<Song id="0" name="Bad Moon R">
<Section name="INTRO" preset="992" scene="5"/>
<Section name="VERSE" preset="992" scene="6"/>
<Section name="CHORUS" preset="992" scene="7"/>
<Section name="BRIDGE" preset="992" scene="8"/>
<Section name="OUTRO" preset="992" scene="5"/>
<Section name="LEAD" preset="992" scene="4"/>
</Song>

The preset in the example above I actually want is 991, but if I put that in the XML file, it pulls up preset 990 once imported because that number in the machine is a 0 based number (zero is first number, not 1) so preset 991 (zero base adjusted) in your machine is preset 992 in the XML. But with the scenes, 1=1, so there you put the actual scene number, not your scene number +1 in the XML scene="".

3. If you get an import error saying "0 files will be overwritten", there is most likely a flaw in the XML document (something in the content that is not supported)! In my testing, it seems that the "&" symbol in song/scene names can cause this but the "@" symbol does NOT cause this. It would be great to have a list of special characters that are/not allowed in these name fields so that I can avoid them when editing my XML outside of the system.

4. It seems that the XML document will allow more than 10 characters in the fields and that will NOT affect the import process of that XML, however the display of those characters >10 will be getting chopped off in views and other scenarios as the display systems are only set to support 10 characters for display. In addition, based on comments made about the allocated space for this information being very minimal, it could poach on some system limits, but I have not tested that far.

Overall, this is a dream for me as I was always running a spreadsheet on my laptop for my setlist, and did not want to create special presets per song, now I can ditch that spreadsheet (although I was also rating the performance each time I did a song via that spreadsheet, so I will need to figure out a new way to keep track of my ratings). Saves me a lot of time and will save me even more in the long run!! Thanks again to the team for giving us this fantastic new feature, LOVIN' IT!!!
 
Last edited:
4. It seems that the XML document will allow more than 10 characters in the fields and that will NOT affect the import process of that XML, however the display of those characters >10 will be getting chopped off in views and other scenarios as the display systems are only set to support 10 characters for display. In addition, based on comments made about the allocated space for this information being very minimal, it could poach on some system limits, but I have not tested that far.
While the file is editable, I suspect the "results are undefined" if something is entered that confuses the XML parser or writes outside the memory available. @Admin M@ can confirm or deny this, but I doubt that the file was intended for us to edit manually, and the firmware very likely wasn't set up to gracefully handle errors or overruns. That said, character encoding should be the same as regular XML.

IF the goal is to allow us to manipulate that file, I already have a wish defined to let us also use YAML or JSON as they're more readable and not so picky. We'll see where it can go.
 
Back
Top Bottom