Helix editor 1.12 - Undo: Come on guys!

[HonestOpinion]

Hooks to do what? Undo?

 

No not necessarily to "Undo", but hooks to objects or code structures that would allow a simple higher level undo using stacked basic commands to be implemented, although ultimately an additional code structure or object(s) solely designed for Undo might be the best way to go.

[ChubbyJerk]

No, hooks to objects or code structures that would allow a simple higher level undo using stacked basic commands to be implemented, although ultimately an additional code structure or object(s) solely designed for Undo might be the best way to go.

But again, in order to build up the stack of basic commands, you need to understand the business logic and chain of events that each action causes. Maybe each action would cause the Helix to send out a series of "state update" messages that could be parsed to put it together. That seems plausible. I wonder if an action in the UI is only reflected in the UI after it gets confirmation from the Helix that it went through. I would guess so, in case communication has been cut or lower level logic (like the 8-assignment limit on a footswitch) prevents it from sticking. I haven't used the app. I assume twisting a physical knob on the Helix is reflected in the app before the patch is saved? If so, there have to be update messages sent.

 

But still, that would still require additional programming to handle, parse, map an update to the command required to undo it, and build up a set of commands into an undo stack. And there's the problem where an update won't necessarily include all info required to undo it; for example, deleting a block probably just gives you an update of "BlockDeleted (dspID, blockID)", and you'd need to handle retrieving and storing all its parameters yourself before clearing it from the UI. Once again, I'm not saying it's undoable by any stretch, but it's unlikely to be straight-forward, simple, or quick.

 

So I guess to answer your question of "how do we know...?" my answer is "we don't", and that's basically my whole point, and has been all along. I said it before, hubris and all that, we don't know. We can speculate, but that's all.

 

At this point I think we're just going around in circles. At least the discourse has been civil, and for that I thank you. :) 

[bobthedog]

Quite the contrary, in my opinion. It's actually good design that makes it so difficult. Encapsulation. Hiding data. Restricting access to functions. Exposing only that which the UI needs for a user to interact with the device. Handling the business logic in the lower levels and letting the UI worry about being a user interface. This is all good, standard practice that makes handling the undo in the UI much more difficult.

 

If you implement undo in the UI, you're giving them access to stuff they shouldn't have access to. You're duplicating logic that should all be handled at the lower levels. That would be bad design.

Wow, talk about fighting a loosing battle.

 

This is why I employ can do developers rather than look how complex it is developers.

[bobthedog]

Hooks to do what? Undo?

I already posted the fact that you can send hlx formatted text to the Helix via the editor. You can try it out, drag you current edit out of the helix application to you filing system. Change some thing In the editor. Now drag that hlx file back to the editor.

 

Is that a "hook" to do undo?

[ChubbyJerk]

Didn't I already say that restoring the entire patch state was a workable solution?

[bobthedog]

I'm not sure what you are saying. Apart from justifying your unjustifiable position.

[ChubbyJerk]

Wow, talk about fighting a loosing battle.

 

This is why I employ can do developers rather than look how complex it is developers.

I agree that there is such a thing as over-engineering the design, but there are a lot of reasons to restrict direct access to the data.

[bobthedog]

You are quite correct, direct access to data is frowned on nowadays.

 

Ideally this sort of thing should be "designed in" from the start. Every method to alter data should have an opposite to alter it back and should register this opposite to revert that data at a future point. This should then be extended to the UI level as well if the change of data originates from a UI interaction. As we undo not only do we need to revert the data we also need to revert the users view of that data.

 

If this has not been designed from the start but we decide it would be nice to have it after the point we need to look at ways of shoehorning it in.

[bobthedog]

Also I need to say that everything you have said is of course true and shows the complexity of doing this sort of stuff.

 

All I was trying to put forward to Line6 is that undo would be very useful to numpties like me who keep making stupid mistakes and implementing this in the editor should not be reliant on the hardware.

 

So no reason for my caustic posts, sorry about that.

[ChubbyJerk]

No worries! It was fairly tame. :)

 

Good discussion. It's just hard to say for sure what would be required with what little info we have. I think it's obvious from what DI said that undo was not planned for when they designed this.

 

I've had to shoe-horn features into code that wasn't designed to include them. It sucks.

[bobthedog]

Good stuff :)

[HonestOpinion]

I already posted the fact that you can send hlx formatted text to the Helix via the editor. You can try it out, drag you current edit out of the helix application to you filing system. Change some thing In the editor. Now drag that hlx file back to the editor.

 

Is that a "hook" to do undo?

 

Very cool! I would say that in some sense this qualifies as a "hook" to executing undo, and at least is an ingenious way to leverage a method already baked into the code of implementing it,  although L6 certainly might approach it differently if they wanted a more nuanced or faster and potentially more transparent method for multi-level undo. It appears to be a good example of safely using high level commands in exactly the same manner the Helix currently saves and loads a preset and would not seem to require any modification to the Helix's existing codeline and only minor changes to the editor. Unless there was a bug in the implementation it should not be any more dangerous or inaccurate than saving or loading a preset is right now. Not saying this is necessarily how Undo should be implemented, simply agreeing that it is low hanging fruit that would certainly get the ball rolling.

[bobwilken]

There is a simple 'undo' feature that will restore the preset to its last-saved state. Switch momentarily to a different preset and then return to the preset-being-edited. I know it's not what's requested, but it can be useful. You can enhance it by saving your desired changes along the way - much like you would do with any file after making changes or adding information that you don't want to lose. If you want to keep intermediate changes, save the preset. If you don't want to save the changes then presumably you're prepared to lose them.

 

You can also copy the preset-being-edited at multiple points to create your own set of 'undo' points. Doing this in conjunction with using the Looper in pre-position will also let you conveniently audition the changes and different versions of the preset.

 

Sure it's not ideal - but you can manage it until/unless the editor incorporates a better way, which certainly sounds like it's not imminent.

 that's exactly what I do when I mess something up ... just click off to another preset then back to the one i messed up ...

of course it's a total patch reset , not a step-by-step ... but it is a usable work around.

[DunedinDragon]

Absolutely not always the case! I have been a developer and beta tester for a huge range of software and soliciting recommendations for improvement and making changes to parts of the UI that users find problematic or in need of tweaking is often part of the process. Otherwise the beta process is nothing other than a QA process utilizing end users as your QA team. Not that this does not happen but it is hardly an ideal use of the resources inherent in a large user base. A beta process at its best should be a feedback process of give and take and more than just a QA exercise.

 

The endgame should be the goal of putting out the best, most well received product possible, catered to the end users needs and requests (within reason, technical constraints, and allotted resources). Line6 did a wonderful job on the editor but implementing some suggestions that came up almost right away during the beta period would make the editor much better. Lastly I would add, if, as you suggest, the design was fixed long before the beta process, then L6 might want to consider getting more users, especially those familiar with UI design, involved in the initial process.

 

I'm not sure what development world you're coming from, but in 3 decades of working in commercial software development for arguably the largest software company in the world that's never been the case.  Beta testing is the very last phase of testing after unit testing and integration testing.  The sole purpose is to achieve stability in usage scenarios that you can't account for in a controlled laboratory testing plan, and is the last step before release.  There's no doubt some of that feeback will flow back into the development cycle for consideration into subsequent releases.  But new features, by definition means they must go back through design, development, and then the entire testing protocol.

 

You're right in saying you want users involved in the design process, but that's at the very start of the product cycle.  Adding features at this point is just asking for instability.  That's the point of gathering feature feedback during the beta as, at least in my experience, where you're beginning to develop the feature list for the next release.

[HonestOpinion]

I'm not sure what development world you're coming from, but in 3 decades of working in commercial software development for arguably the largest software company in the world that's never been the case.  Beta testing is the very last phase of testing after unit testing and integration testing.  ...

 

I thought this discussion had been put to bed, I never suspected what a difference of opinion on beta testing there would be and how strongly people would feel about it. I don't want to get into a contest about who has more experience but I also have designed software for some of the largest companies in the world and my experience is that the process of beta testing differs from shop to shop, app to app. Anyway, I have no ego invested in this, I simply want to see some of the better suggestions from the beta tests incorporated into the Helix. I don't really care what that process ends up being as long as it happens and I certainly have no desire to delegitimize the experience of other developers and software professionals. I was simply pointing out that I have seen all manner of development, test, and QA, processes implemented over the years. whatever gets us there. I think L6 needed to get the Editor out and they did the right thing by releasing it.  I hope future versions take into account some of the needs and suggestions of their user base.

 

Here is a fairly decent link for the difference between alpha and beta testing although the definition of a beta test is somewhat fluid from company to company. I think it supports an argument from either side of the fence of what exactly the use and results of a beta test should be and we have certainly seen that in this topic. Perhaps an argument could be made that alpha testing with a wider audience should have been attempted but I can certainly see the difficulty of doing that. It probably is not practical with a consumer base that may have well been left with presets that did not load properly from version to version or major bugs that would have exploded in forum posts.

 

http://www.centercode.com/blog/2011/01/alpha-vs-beta-testing/

[spaceatl]

I'm not sure what development world you're coming from, but in 3 decades of working in commercial software development for arguably the largest software company in the world that's never been the case.  Beta testing is the very last phase of testing after unit testing and integration testing.  The sole purpose is to achieve stability in usage scenarios that you can't account for in a controlled laboratory testing plan, and is the last step before release.  There's no doubt some of that feeback will flow back into the development cycle for consideration into subsequent releases.  But new features, by definition means they must go back through design, development, and then the entire testing protocol.

 

You're right in saying you want users involved in the design process, but that's at the very start of the product cycle.  Adding features at this point is just asking for instability.  That's the point of gathering feature feedback during the beta as, at least in my experience, where you're beginning to develop the feature list for the next release.

Was that you wearing the dunce hat all day for breaking the build?

[DunedinDragon]

I thought this discussion had been put to bed, I never suspected what a difference of opinion on beta testing there would be and how strongly people would feel about it. I don't want to get into a contest about who has more experience but I also have designed software for some of the largest companies in the world and my experience is that the process of beta testing differs from shop to shop, app to app. Anyway, I have no ego invested in this, I simply want to see some of the better suggestions from the beta tests incorporated into the Helix. I don't really care what that process ends up being as long as it happens and I certainly have no desire to delegitimize the experience of other developers and software professionals. I was simply pointing out that I have seen all manner of development, test, and QA, processes implemented over the years. whatever gets us there. I think L6 needed to get the Editor out and they did the right thing by releasing it.  I hope future versions take into account some of the needs and suggestions of their user base.

 

Here is a fairly decent link for the difference between alpha and beta testing although the definition of a beta test is somewhat fluid from company to company. I think it supports an argument from either side of the fence of what exactly the use and results of a beta test should be and we have certainly seen that in this topic. Perhaps an argument could be made that alpha testing with a wider audience should have been attempted but I can certainly see the difficulty of doing that. It probably is not practical with a consumer base that may have well been left with presets that did not load properly from version to version or major bugs that would have exploded in forum posts.

 

http://www.centercode.com/blog/2011/01/alpha-vs-beta-testing/

 

Well you're exactly right.  There's a much more fluid definition of Beta when it comes to corporate development.  And that's driven largely by whatever department or entity is footing the bill for the product development.  In some cases I'd say there never really is a "formal" release..just an ongoing series of improvements in a base piece of software.

 

Commercial software really only gets paid once the product ships, so things are quite a bit more stringent.  This is especially true when your corporate buying customers have thousands of desktops to deploy it to and there needs to be some level of version control across the enterprise in order to manage their support costs.

 

Although technically the editor is a commercial product, it's a FREE commercial product so a case could be argued that it should be more like an ongoing series of improvement like some corporate products.  It's really up to L6 how they want to handle it.  I'm not put off either way since I'm not really invested in their editor other than for saving and restoring patches.  As long as they don't break that, I'll be fine.

 

I would still think L6 has to look at the support costs that come along with keeping track of which bugs and features are related to which release so they can support the customer base which will undoubtedly have a hodgepodge of various versions of the editor if they were to treat this as an ongoing product improvement exercise.  I suspect that's what's playing into wanting to "lock down" the features at some point so they can move onto new features for a future release.

[ChubbyJerk]

Well, one key thing to note is that there has been a drastic shift in standard software practices in recent years. Waterfall is less common, Agile is more common. It's far easier to incorporate new features into a product closer to release with Agile than it is with Waterfall. Furthermore, the ubiquitous nature of the internet is also changing things drastically. Everything can be patched nowadays. Everything is expected to be patched these days. When you buy a product like this, you know it will receive updates. That's still a relatively new phenomenon, and it is a big change.

[PeterHamm]

...That's still a relatively annoying phenomenon, and it is a big change.

 

Fixed it for ya.

 

Seriously, all these updates are annoying, especially when one patch creates other problems. Whether that's my iPhone or my Mac, these little incremental patches seem to cause more harm than good.

 

I think the whole computing industry is retreating in reliability and effectiveness the past few years. Witness the multiple debacles connected with the last two MacOS updates, and the forced Windows 10 updates that have caused a bunch of people great consternation. Super annoying.

[DunedinDragon]

Fixed it for ya.

 

Seriously, all these updates are annoying, especially when one patch creates other problems. Whether that's my iPhone or my Mac, these little incremental patches seem to cause more harm than good.

 

I think the whole computing industry is retreating in reliability and effectiveness the past few years. Witness the multiple debacles connected with the last two MacOS updates, and the forced Windows 10 updates that have caused a bunch of people great consternation. Super annoying.

 

EXACTLY!!!!

 

I think the marketing people have taken over and in trying to appease a generation of millennials that expect everything RIGHT NOW have unleashed a torrent of inadequately designed and tested software products that are about as stable as jell-o.

[bobthedog]

Well, one key thing to note is that there has been a drastic shift in standard software practices in recent years. Waterfall is less common, Agile is more common. It's far easier to incorporate new features into a product closer to release with Agile than it is with Waterfall. Furthermore, the ubiquitous nature of the internet is also changing things drastically. Everything can be patched nowadays. Everything is expected to be patched these days. When you buy a product like this, you know it will receive updates. That's still a relatively new phenomenon, and it is a big change.

 

I wouldn't call it relatively new, for the general public its been going on for quite a few years, since they connected to the internet as you say, but quite a few years.

 

For corporate use years longer.

 

What has changed is "developers" writing more testing code than real code, this is detrimental to quality. Who watches the watchers.

[Adam--]

I wouldn't call it relatively new, for the general public its been going on for quite a few years, since they connected to the internet as you say, but quite a few years.

 

For corporate use years longer.

 

What has changed is "developers" writing more testing code than real code, this is detrimental to quality. Who watches the watchers.

 

Are you claiming testing code reduces quality?

[bobthedog]

Not testing, testing improves quality.

 

Spending a large amount of time writing software that tests software does reduce quality.

 

Actually I should qualify that: : Spending a large amount of time writing software that unit tests software does reduce quality.

[Adam-]

Not testing, testing improves quality.

 

Spending a large amount of time writing software that tests software does reduce quality.

 

Actually I should qualify that: : Spending a large amount of time writing software that unit tests software does reduce quality.

 

That's a pretty bold claim; do you have anything to back that?

[bobthedog]

Only personal experience, nothing more.

[Adam-]

Only personal experience, nothing more.

 

Gotcha.

[HonestOpinion]

I wouldn't call it relatively new, for the general public its been going on for quite a few years, since they connected to the internet as you say, but quite a few years.

 

For corporate use years longer.

 

What has changed is "developers" writing more testing code than real code, this is detrimental to quality. Who watches the watchers.

You have a point in that it is always a matter of achieving balance and you can definitely reach a point of diminishing returns where limited resources can be tilted too far towards testing and not enough to creating. That is one of the reasons why I am such a fan of automated test harnesses where possible. Although they may take some time to code initially they can be a real time saver for repeated test iterations and also cut down on things missed by more manual methods.

 

You do have to take into account the nature of the software and its usage. If you are writing software for Wall Street that can tank the markets if it has errors, the testing has to be fairly rigorous. Same goes for if you are doing a Moon launch at Cape Canaveral and bad software means a bunch of astronauts never make it home (although ironically the Helix software is far more complex than the software that sent the original astronauts to the Moon), or if you are writing the software that supports the power grid, or an air traffic control system. So granted that Helix does not come close to hitting any of these thresholds but it is used for live performance and everything that implies from one-time events like weddings to internationally filmed concerts with thousands of attendees, and therefor does require a certain level of reliability.

 

If you are constantly reintroducing old bugs, or introducing new bugs with every upgrade it may be time to take a closer look at your development and testing process, you may be erring on the side of the equation that is not testing thoroughly enough, although bugs crop up in even the best software shops. Anyway, I hope the tap tempo bug get fixed soon as I think it is fairly substantial and I still would like to have at least heard an explanation from L6 as to why this one did not warrant a quickfix, or why a quickfix was not feasible. I ask this humbly as the programmers at L6 are doing things far beyond my own feeble talents. I am mollified in the meantime by the distinct feeling that some substantial new features and additions are headed our way.

[spikey]

Line6 did a wonderful job on the editor but implementing some suggestions that came up almost right away during the beta period would make the editor much better.

 

 

If you are constantly reintroducing old bugs, or introducing new bugs with every upgrade it may be time to take a closer look at your development and testing process, you may be erring on the side of the equation that is not testing thoroughly enough

 

 

 

And if mother had wheels she'd be a wagon....  ;)  Icing and the cake too? Im sure that they are doing what their time frame allows. They like to eat too, so the more Helix sells the better the bonus for Line-6, which filters down to the programmers and designers at some point. In other words, give them the time, let them program, and more good things will come...  :D

[ChubbyJerk]

I wouldn't call it relatively new, for the general public its been going on for quite a few years, since they connected to the internet as you say, but quite a few years.

 

For corporate use years longer.

 

What has changed is "developers" writing more testing code than real code, this is detrimental to quality. Who watches the watchers.

It has been possible for years. The ubiquitous nature of it, which is what I commented on, is fairly recent. That is to say, what was possible before has only recently become common practice, i.e., expected of companies, demanded by consumers, available in most cases, etc.

 

While you could update a handful of pedals 10 years ago, it was not nearly as prevalent as it is now. I had some that I'm assuming could have possibly been updated (early Digitech, Zoom, and Line 6 digital multi-fx pedals), but I personally never did. There was nothing, to the best of my knowledge, like the massive content updates that Line 6 et al make available now, entirely new fx and amp models that weren't shipped with the unit.

 

There are certainly other things you could base this on, but a big factor that pushed us from the old standard to the constant always-available nature of updates here and now was the release of the iPhone, which was ca. 2007, less than 10 years ago. Did phones get updates before that? Flip-phones? Um...maybe? I had several, but I don't remember. If they got them, I didn't notice or care. Somewhere in that same general timeframe, the PS3 and XBox 360 started heavily trending the same way - direct download of games, patches, and add-ons.

 

And so on. Again, this is not talking about the general possibility. As soon as you have a consumer connected to the internet it's possible. Heck, as soon as you have them register a product you can ship them an update disc. I'm talking about expectations and prevalence. Ubiquity.

 

If you don't think 2007 is relatively recent, then I guess we're looking at different timelines.

 

This is a rather silly thing to nitpick about though.

 

Regardless, to what others have said...sure, there are downsides. But there are also big advantages to the consumers. I think the pros outweigh the cons.

[bobthedog]

Windows update was originally in windows 95, a fair few years before 2007.

[ChubbyJerk]

Windows update was originally in windows 95, a fair few years before 2007.

Well, you're either deliberately misinterpreting what I said or your reading comprehension is seriously lacking, so I'm done.

[bobthedog]

Well, you're either deliberately misinterpreting what I said or your reading comprehension is seriously lacking, so I'm done.

 

I' not sure why you are taking that tone with me?

 

As far as I can see (and I have read your post again) you are saying that it has only become common practice since 2007. You are quite obviously wrong here!

 

Edit: Looked back over the entire thread, you were the same guy that was originally arguing with me over the undo. Now I understand.

[ChubbyJerk]

I' not sure why you are taking that tone with me?

 

As far as I can see (and I have read your post again) you are saying that it has only become common practice since 2007. You are quite obviously wrong here!

 

Ok, dude. Maybe you're sincere. I'll give you the benefit of the doubt. If you're trolling, congratulations, you hooked me back in. I will try my hardest to be calm and polite (though I'm not sure what you mean by "that tone", it's not like I was terribly rude previously).

 

I never ever ever said that updates in general were a new invention, or that patches were a new thing. I said expecting everything to get patches and updates was a relatively new thing.

 

Let's start by defining a couple key words I used in my posts. I apologize if this seems condescending, but it seems necessary at this point.

 

ubiquitous:

existing or being everywhere at the same time :  constantly encountered :  widespread

 

prevalent:

accepted, done, or happening often or over a large area at a particular time : common or widespread

 

So let's compare the 90s to today.

 

Things that regular updates in the 90s:

OS (Windows, etc)

 

Things that get regular updates today:

OS

Phones

PC Applications

Phone apps

Digital guitar pedals

 

How often would you expect an update in the 90s? Windows had the automatic updates once a month I think, right? So you would encounter 1 thing that wanted to update 1 time a month.

 

How often do you see updates, in general, now? I personally get app updates just about every day. Every week at a minimum.

 

In the 90s, your video game consoles had no way of getting updates, at all, period. You bought the cartridge (or disc, eventually), and that was the game. Now, the first thing most games will do when you buy them is connect for an update! Some games have regularly scheduled patches and updates, like every week.

 

Heck, we have cars that get firmware updates now! Watches! Thermostats, dishwashers, washers and dryers! Refrigerators!

 

Updates: not new

Getting constantly inundated with updates from every direction: relatively new

 

FYI, just in case:

inundate:

to cause (someone or something) to receive or take in a large amount of things at the same time