POD HD v2.6 FIRMWARE

[duncann]

Where did this 4% come from? I said that because some optimization was required to accommodate the Global EQ, there's a chance you might (MIGHT) get a bit more DSP—a few percent perhaps. Certainly not enough for an extra block, but maybe enough to add that one model where before you couldn't (dependent on the model, of course).

 

Then again, you may not notice any difference at all.

 

I hope I didn't misunderstand what you said, and I don't think I did because you just said it again above, "a few percent perhaps". Which is essentially what I said by saying a "possible ~4%", note the word possible and the tilde character. What I said exactly is below. But again, I'm resorting to my memory, which is for certain fallible. :)

 

duncann, on 15 Feb 2015 - 7:16 PM, said:

I remember Digital_Igloo saying that the engineers were able to optimize some code while implementing the new EQ that would allow for a possible ~4% extra DSP, as compared to the firmware versions prior to 2.6.

[daedae]

Hm...I must've misread (or misunderstood) DI's original post, because I thought the point was that the global EQ and some changes required for it would USE around 4% more DSP, not free up that much DSP.

[Charlie_Watt]

I don't see how adding a feature like Global EQ can reduce the DSP overhead. (Unless you replace an existing EQ or other Effect)

[nupmoh]

If I own an HD PRO X and a HD500 (no x), am I going to have to buy the updates twice? 

Please say no

[NucleusX]

After all the political corrections to statements, I still don't see where that extra %4 (give or take) came from.

Can you tell us EXACTLY what was done to achieve this, I think most of use are assuming a slight increase

in available DSP, resulted from a decrease or trade-off in something "elsewhere". specifics please !

[lefttygtr]

So what else is in the upgrade? new amp packs you have to buy and a global eq, is that it?

[NucleusX]

The v2.6 firmware (free) just gives you a global EQ, and maybe some optimizations to "accommodate" expansions, but they should be considered separate.

[pianoguyy]

After all the political corrections to statements, I still don't see where that extra %4 (give or take) came from.

Can you tell us EXACTLY what was done to achieve this, I think most of use are assuming a slight increase

in available DSP, resulted from a decrease or trade-off in something "elsewhere". specifics please !

I guess a good way to explain it is... 

 

Audio technology. We once had Wave files that took up 40mb. 

Then we got MP3 that could do the same with 2mb. 

 

As technology advances, it takes less to produce the same. So, they can tweak a few this and rearrange a few that --- and you free up some DSP. 

[NucleusX]

Your audio file format "analogy" also has a trade-off, your 2mb MP3 also comes at a quality cost due to compression.

I appreciate the response, but its not a direct answer to this specific question. Most know trade-offs are inevitable in

situations like this, and I think D.I. is the only candidate that can accurately explain what that is in this situation.

Personally, I'm VERY interested to know this above all else, I'd like to know the downsides, if any, don't you ?

[duncann]

Your audio file format "analogy" also has a trade-off, your 2mb MP3 also comes at a quality cost due to compression.

I appreciate the response, but its not a direct answer to this specific question. Most know trade-offs are inevitable in

situations like this, and I think D.I. is the only candidate that can accurately explain what that is in this situation.

Personally, I'm VERY interested to know this above all else, I'd like to know the downsides, if any, don't you ?

 

It's probably nothing more than the software engineers finding a way to do something more efficiently somewhere in the firmware. Now in some cases, unknown to all of us, there's a shorter DSP distance from point A to point B. The programming instructions for a given task are reorganized in a way to get that task done with less resources, and probably with a certain elegance from the programmers point of view.

 

Have you ever read a book where the writing style is kind of bloated? There's a lot of information that's either unnecessary, or could be condensed to convey the same information in one sentence rather than an entire paragraph of four sentences.

 

As to what specifically might have changed, you'd have to talk to the software engineers and probably have an understanding of the programming language they use. And if there's any downsides, it would be the introduction of unwanted behavior, or bugs, because DI said none of the existing amp models have changed.

[Triryche]

if I remember correctly I believe that with the same license you can install the model packs on 4 devices registered by you

 

That's how it's been for the POD Farm, GX, UX, KB37, XT, and X3 series.

 

Hopefully it will be the same for the HD series.

[TheRealZap]

that's all that they've announced... but it's not done yet... so we'll see if anything more has changed when it's released.

 

So what else is in the upgrade? new amp packs you have to buy and a global eq, is that it?

[JFrankParnell]

How do you know which models are HD and which arent?

[Triryche]

http://line6.com/support/topic/11509-seems-theres-something-on-the-way-for-guitarists-at-namm/page-2?do=findComment&comment=79083

[Digital_Igloo]

Can you tell us EXACTLY what was done to achieve this, I think most of use are assuming a slight increase

in available DSP, resulted from a decrease or trade-off in something "elsewhere". specifics please !

 

There are zero sonic tradeoffs—this is nothing like data compression. All code can and should be optimized, and POD HD500 was optimized from the outset. Adding a Global EQ would be impossible without optimization because... what happens to all the presets that are at 99% of capacity? So our gurus dug in and figured out a way to further optimize enough of the DSP code in a POD HD500X/Pro X to accommodate an additional 5-band Global EQ. Surprisingly, they were able to optimize enough to also squeeze it into HD500, HD Pro, and HD Bean. Bonus.

 

Please, everyone stop with this 4% nonsense. There is no 4%. If you see a bit more DSP available, cool; it's just as likely that you won't. Not enough to write home about, and certainly not enough for us to talk about in ad copy.

[ColonelForbin]

So, it's essentially 8 new HD guitar amp models + 2 new cabinet (JC120 and Fender Champ) + the 5 HD bass models

 

New HD Models:

1. Peavey 5150 (block logo),

2. Bogner Shiva,

3. Remastered JCM800 (model 2204)

4. Orange OR-80

5. Roland JC-120

6. Fender Champ (Tweed)

7. VOX AC30 Fawn Normal

8. VOX AC30 Fawn Bright

9. JC-120 cab

10. Fender Champ cab

 

POD Farm models:

1. Insane,

2. Big Bottom,

3. Varaic'ed Plexi,

4. Purge,

5. Aggro,

6. Smash

7. Octone

8. POD Farm Acoustic

 

Bass Pack: (HD)

1. Ampeg SVT Normal,

2. Ampeg SVT Bright,

3. Gallien-Kruger 800RB,

4. SVT 8x10 cab,

5. SVT 410 HLF cab

[Triryche]

Please, everyone stop with this 4% nonsense. There is no 4%. If you see a bit more DSP available, cool; it's just as likely that you won't. Not enough to write home about, and certainly not enough for us to talk about in ad copy.

 

So are you saying it is more like 3.999% ?

 

JK :lol: :lol: :lol:

[JFrankParnell]

How do you know which models are HD and which arent?

http://line6.com/support/topic/11509-seems-theres-something-on-the-way-for-guitarists-at-namm/page-2?do=findComment&comment=79083

 

 Does this mean that the new models, coming in this future firmware are HD, but the current models are not?

[Triryche]

All the current models are the HD algorithms.

 

The Model Packs that will be available for purchase with the FW update have new HD models and some POD Farm/xt/X3 series models.

[amsdenj]

What specific POD Farm Acoustic is being included?

American Classic

Console

Lo-Fi

Modern

Vintage

Vintage UK

Tube Preamp

 

And will this preamp be HD? Or does HD mostly mean how closely the model reproduces the original, rather than the performance of the model (frequency range, distortion characteristics, etc.). That is, I want to use this for acoustic instruments and not have it strip of the instruments tone the way the POD X3Live did.

 

Is HD really mostly about the cabinet impulse responses? These seem to make a very big difference in software amp modelers.

[TheRealZap]

HD is a newer way of modeling the amps and effects....

the included pod farm models will only be translated to the HD platform.. they will not be remodeled.... so therefore they will not be HD.

i suspect that there will be some difference from the pod farm/x-series models... because they will be paired with m-series effects for example...

i also suspect that they won't be a radical departure from what everyone knows on the pod farm/x-series...

as for which one.... not sure.

[radatats]

What is the Orange OR-80?  I've googled it and can't find it and there is no record of it on the Orange web site even in the discontinued models...

 

https://www.orangeamps.com/support/downloads/

 

Nevermind... found some info on this page:

 

http://www.orangefieldguide.com/

 

Of all the awesome Orange amps they picked this old chestnut... I will just have to be pleasantly surprised to try it...

 

Thanks for all the responses by the way.

[clay-man]

After all the political corrections to statements, I still don't see where that extra %4 (give or take) came from.

Can you tell us EXACTLY what was done to achieve this, I think most of use are assuming a slight increase

in available DSP, resulted from a decrease or trade-off in something "elsewhere". specifics please !

 

Optimizing coding..

[ColonelForbin]

Found this...

 

1970's Orange OR-80 and an SD Curlee Guitar: http://youtu.be/OkYY5qJ1Gqo

[wicker_man]

Some info on a 1972 OR-80:  http://tymguitars.com.au/blogs/blog/8787301-1972-orange-or80

 

And another video:Orange OR80 - YouTube

[NucleusX]

Digital_Igloo

 

"There are zero sonic tradeoffs—this is nothing like data compression. All code can and should be optimized, and POD HD500 was optimized from the outset. Adding a Global EQ would be impossible without optimization because... what happens to all the presets that are at 99% of capacity? So our gurus dug in and figured out a way to further optimize enough of the DSP code in a POD HD500X/Pro X to accommodate an additional 5-band Global EQ. Surprisingly, they were able to optimize enough to also squeeze it into HD500, HD Pro, and HD Bean. Bonus.

 

Please, everyone stop with this 4% nonsense. There is no 4%. If you see a bit more DSP available, cool; it's just as likely that you won't. Not enough to write home about, and certainly not enough for us to talk about in ad copy."

 

 

 

I had a hint it might've been efficient coding, so if it was already efficient, good work for squeezing the EQ

in at zero sonic/resource cost ! well done. The question was an important one tho, so thanks for clarifying.

[Robert0]

Acoustic

[Robert0]

Hi, my question about the new firmware is,

If the acoustic model is for acoustic/electric guitars?

[joel_brown]

A very brief summary of how code can be optimized.  When I say brief, this is barely the tip of the iceburg.  But this is how they may have got the ~4% more available DSP.  Actually what they got was their code to be ~4% more efficient.

 

In general, savings can be made by trading off memory for speed. If you can cache any often used data rather than recalculating or reloading it, it will help. Examples of this would be sine/cosine tables, or tables of pseudo-random numbers (calculate 1000 once at the start, and just reuse them if you don't need truly random numbers).

• Avoid using ++ and -- etc. within loop expressions. E.g.: while(n--){}, as this can sometimes be harder to optimize.
• Minimize the use of global variables.
• Declare anything within a file (external to functions) as static, unless it is intended to be global.
• Use word-size variables if you can, as the machine can work with these better (instead of char, short, double, bit fields etc.).
• Don't use recursion. Recursion can be very elegant and neat, but creates many more function calls which can become a large overhead.
• Avoid the sqrt() square root function in loops - calculating square roots is very CPU intensive.
• Single dimension arrays are faster than multi-dimension arrays.
• Compilers can often optimize a whole file - avoid splitting off closely related functions into separate files, the compiler will do better if it can see both of them together (it might be able to inline the code, for example).
• Single precision math may be faster than double precision - there is often a compiler switch for this.
• Floating point multiplication is often faster than division - use val * 0.5 instead of val / 2.0.
• Addition is quicker than multiplication - use val + val + val instead of val * 3. puts() is quicker than printf(), although less flexible.
• Use #defined macros instead of commonly used tiny functions - sometimes the bulk of CPU usage can be tracked down to a small external function being called thousands of times in a tight loop. Replacing it with a macro to perform the same job will remove the overhead of all those function calls, and allow the compiler to be more aggressive in its optimization..
• Binary/unformatted file access is faster than formatted access, as the machine does not have to convert between human-readable ASCII and machine-readable binary. If you don't actually need to read the data in a file yourself, consider making it a binary file.
• If your library supports the mallopt() function (for controlling malloc), use it. The MAXFAST setting can make significant improvements to code that does a lot of malloc work. If a particular structure is created/destroyed many times a second, try setting the mallopt options to work best with that size.

[duncann]

Interesting. I take it you must have programming experience?

 

I wonder, though, what language they use, because what they do can't be like writing programs for generalized computers, can it? How much of what they do is actually written in assembler. By the way I'm not a programmer, but I do remember messing around with it in the days of apple IIe computers.

 

Finally, DI is going to come back and start complaining about the ~4% number again. lol.

[Charlie_Watt]

Most DSP code is written in C or C++ these days.  Compilers have gotten pretty good at optimizing the code.  It still pays to know what creates efficient code.  I write C++ code for ARM processors which have fairly decent DSP capability.  Pods use Analog Devices processors.

[ColonelForbin]

It's actually 4.20%

 

;)  (add mandatory "Just Kidding!!!" tagline; DI does a great job keeping us all in the loop, don't want to get him riled up more!) :)

[ryechua]

Interesting. I take it you must have programming experience?

 

I wonder, though, what language they use, because what they do can't be like writing programs for generalized computers, can it? How much of what they do is actually written in assembler. By the way I'm not a programmer, but I do remember messing around with it in the days of apple IIe computers.

 

Finally, DI is going to come back and start complaining about the ~4% number again. lol.

 

i believe that was taken from this article:

 

http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization

[duncann]

i believe that was taken from this article:

 

http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization

 

Looks like it.

 

Here's a link, http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&cad=rja&uact=8&ved=0CGoQFjAL&url=http%3A%2F%2Fcds.cern.ch%2Frecord%2F1100536%2Ffiles%2Fp167.pdf&ei=CfzpVNkMib-CBP2ihPgL&usg=AFQjCNFkqWFDHy5oKiV9u6nrQvMsxIWskg&sig2=ewI_-8In0XYPdQ0AI3OfFg, to a pdf that talks about the fundamentals of programming DSPs. Mention of Sharc processors are in there, goes into some amount depth and also talks about different programming languages.

[stumblinman]

Hm...I must've misread (or misunderstood) DI's original post, because I thought the point was that the global EQ and some changes required for it would USE around 4% more DSP, not free up that much DSP.

That was what I interpreted as well.

[Triryche]

I'm pretty sure DI said you get 3.14159265358979323846264338327950288419716939937510582% more DSP, but you need a Nintendo Game Boy and you have to request an HD to Game Boy interface cable.

 

[disclosure: this is a poor attempt at humor, the above statement is not true]

[silverhead]

...and you also need a piece of pie, preferably one that won't repeat on you.

[rhandy]

Last new Update about release date!!!

Hi,
The new firmware 2.6 will be available in mid April. It is not out yet. The firmware will be free, but if you want more aviable amps, that will cost money. The free firmware update will fix some security bugs, and add a global EQ setting.

I hope this helps you out.

Regards,
Will - Line 6 Support

Is an answer to be because I buy my POD HD500x in 15 of this month !

[edstar1960]

That was what I interpreted as well.

 

Reading his posts again, I think he is saying that the GLOBAL EQ requires DSP to run (just like any other fx) but they needed to guarantee that there will always be sufficient spare DSP for it to run with existing patches that users have already made specifically those that are already close the MAX DSP usage - otherwise those users are going to be very angry when they discover they have to change their existing patches to make use of the new GLOBAL EQ. So to prepare for this eventuality they looked at ways of making the existing code for amps and fx more efficient so they use slightly less DSP,  and they were successful in optimising existing code meaning that anyone with a patch that is currently very close to max DSP usage will still be able to use that existing patch at the new firmware level with the GLOBAL EQ switched on and not hit the DSP limit.

[panaman]

sure hope the eq will be switchable. and if it is, there must be extra dsp free.

5band eq with lo and hi cut might take a little over 4% hopefully