Please ensure Javascript is enabled for purposes of website accessibility Jump to content

ChubbyJerk

Members
  • Posts

    63
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by ChubbyJerk

  1. Sure. And the appropriate hook to expose that allows this functionality would be "Undo". Which is not in the firmware. Which is the whole point of this. We're right back where we started, aren't we? Either a) the firmware needs to support Undo, or 2) the UI needs to understand the business logic (since there's no Undo in the firmware, there's no simple hook to expose here), or, option 3), which I already suggested as a possible solution, the UI handles Undo by loading restore points with the entire patch data.
  2. 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.
  3. Let's take a simple scenario. You have a full line of effects in your top chain. You have a single EQ pedal in the split chain. You delete that lone EQ pedal. What does the app need to store in order to undo that delete, and how does it restore that pedal? The specific value changed is simple: Block Location + Effect ID. That's all the user is changing. But what do we need to store to undo it? What does the Helix do behind the scenes? For starters, the app needs to not just store the block location and effect ID, it needs to store all of the effect's parameters. But it goes beyond that. To undo it, first it needs to create the pedal in the same spot, right? Except it can't, because as soon as that pedal is gone the empty chain disappears. You can't create a pedal in a block down there if the chain isn't there, you need to create it somewhere else and then move it. The app needs to know that. Ok, so it creates it in the chain above! Except that's full. Ok, so it finds an empty spot somewhere and creates in and then moves it. And then it has to go through and set each parameter. And then there's stuff like the footswitch assignment. You can assign 8 things to a single footswitch. Handling undo on one to many relationships is fun! Difficult? Rocket science? No, of course not. I've had to do it before. It goes beyond the simple "store the old parameter and call SetValue on Undo". You need to understand how to handle each specific case. Let's say you have 5 assignments, and the user calls AddAssignment, which passes in FootswitchID, BlockID, ParameterID, FootswitchOnValue, FootswitchOffValue, and Merge. So now you need to know that if they passed in Merge as true, Undo means you call RemoveAssignment (FootswitchID, BlockID) to go back to the original 5 assignments. Oh, hey, that message may not even exist! Is there a way to remove a single assignment from a footswitch that has several set? I don't know. So you may need to call ClearAllAssignments(FootswitchID) and then loop through and AddAssignment. Or you call AddAssignment for its first assignment with Merge set to false (which will internally ClearAllAssignments and then AddAssignment), and then AddAssignment for all the others with Merge set to true. It all depends on the Helix firmware and messaging and what commands are exposed to the outside world. Point being, we don't know. And then you need to know how to handle it if Merge is false. So really...is this rocket science? No, absolutely not. It's entirely doable. But the application needs to know how to do a lot of things that the firmware does automatically. It needs to understand the chain of events that each action would have. It may not be difficult, but neither is it trivial. It is, at best, tedious and time consuming, because they need to go through everything in the whole Helix and map out what steps are required to reverse everything the user can do, and that changes depending on the state of other things around it. The only reasonable way to do it in the app would be to store the entire state of the patch for each undo, but again, that's resource-intensive.
  4. Just two quick points. We're not far enough apart in opinions to get bogged down in a big debate. :) A) Eh, not really. It obviously depends on the size / scope / depth / extent of the change, but overall I stand by what I said. It's dangerous to make large changes late in the game. You need to be very careful when doing so. Again, it obviously depends on the scope of the change. As a release date approaches, many places implement strict code freezes for this very reason; nothing but bug fixes merged into the main branch after that point, period. B) Really, that's my main point, summarized pretty well. We don't have all the information they do. Not even close. It's the height of hubris to take what little info we have and tell them something would be easy.
  5. I don't really think you two disagreed much here. There is an ocean of difference between "new features" and "improvements" or "tweaks". Feature set is unlikely to change much, if at all, by the time a product is ready for beta testing. If it changes, it's far more likely to be features dropped for the sake of meeting deadlines than it is to be features added. That's simply the way the world tends to work, unfortunately. Sure, you can find exceptions to this, but I doubt you'll find many. Modifications, tweaks, enhancements, and so on...sure, there's a better chance those will make it in. It depends on the scope of the change. Let's be honest. The primary value of beta testing is extended QA, pure and simple. There is no way your QA department will hit everything. Users will have a wider variety of hardware (processors, video cards, operating systems, and on and on) in a wider arrangement than any QA department could ever possibly replicate. They will do a much wider range of things with the product too. I've seen some extensive test plans and test procedures, but there are always cases where you end up saying, "huh, I didn't think to try that." The most important thing in beta testing is to squash as many bugs as you can, plain and simple. Management will never say, "holy crap this idea from BetaTester_01 is brilliant, we can't release until we implement it!" They will, however, say, "mother ****er, how did we miss this bug?!? We can't release until it's resolved." When you beta test, that is your job. Find bugs. You're making a trade - early access to try out the product in exchange for reporting bugs. That's their main priority at that point. They may like feature requests and ideas for tweaks, they may run them by management as ideas to be implemented in the future, but they'd trade a single show-stopping bug report for a dozen ideas for nice little tweaks. Now end user feedback is good. Great even. But really, 1) feature set is likely not changing (for release 1.0) at that point. 2) The management very likely already have a set of new features for the next release planned. 3) The developers very likely have a set of things they argued for but were shut down on due to schedule or money. 4) If your idea is genuinely a good one, it's likely already covered by 2 (planned future features) or 3 (ideas that were shot down) or for some reason you don't know it's unfeasible. 5) A heck of a lot of this stuff, features and usability, particularly when it comes to UI implementation, is personal preference. What one user likes two others will hate. Your beta testers are not necessarily a good representative sample of your final end users. Feature changes based on beta feedback are dangerous. 6) If they're using their heads, they already have market research, user feedback, etc, that went into the design stages. Do you think they came up with this product in a vacuum? 7) Beta tests are typically occurring when the product is getting close to release. What's the top priority at that point? Bugs, bugs, bugs. Even if you could get past all the other reasons that your idea is unlikely to get implemented, you still have a team of developers who are overloaded with bug fixes they're scrambling to get in so that they can meet the release date without show-stopping issues killing them. Long story short, sure, they should pay attention to beta user feedback, absolutely. But there are a lot of reasons why beta user feedback is unlikely to get implemented (short-term) beyond bug fixes.
  6. Here's a concrete example from another Undo scenario that may help clarify what I mean. In VisualStudio, copy a block of code from inside brackets (in an if block, for example). Paste it outside the brackets. Then undo it. What happens? If I explained the steps clearly enough for you to do it the way I'm thinking, the code you pasted is still there after you undo, it's just indented more. Your undo didn't undo the last user action, it undid an automatic reformatting that the application did. It takes 2 undo actions to get rid of your 1 user action. And that's for a simple copy/paste in what is essentially a glorified text editor. Now try applying that to the vast array of disparate functions you can do in editing a Helix patch. If you change an effect from one Drive to another, is that one action, or is it two? Does the Helix delete the block and then add the new one behind the scenes? If so, would a single undo leave you with an empty block, and the second undo give you back your original? When you assign an action to a footswitch, you can overwrite the previous assignment. What if the assignment was a toggle for several other effects? The assignment you just did is probably two Helix actions (or more), Clear Assignment, Add Assignment. Undoing that, however, is more complicated. You probably have a Clear Assignment, and then a loop to Add Assignment for each of the previously assigned pedals. I highly doubt Helix can do a multi-assignment in a single message. What if you move a block around? Each movement is probably a single action to undo on the Helix. Plus, if you go through/past/around other blocks, you might have Move Block actions for those other blocks all encapsulated in that one user action of moving a completely different block. What if you move a block down to the second signal path, and that path was previously empty? You probably have some hidden Helix changes there to create the second signal path. It's not an insurmountable problem, but you greatly oversimplified it and glossed over some tricky details. That's all I'm saying.
  7. There are still several obstacles to deal with. Some examples... What if they don't move on to another parameter? What if they tweak a bit, then play a few chords, then tweak more, then play a few chords...set drive to 5.5 and try it, decide they need more, set it to 6.5, nah still need more, set it to 8.0 WHOAH too far, I want to undo that...where does the undo take them then? Do you go all the way back down to 0? Then they're like wait wtf where'd my last update go? Do you go back to 6.5? Ideally, sure, but what triggered the app to store that specific value? And would every user agree? And then there's the fact that an update could be anything - tweak a parameter, add a block, delete a block, move a block, change the signal path, switch the selected model in a block, toggle a block on/off, change a scribble strip, add or remove an effect to a footswitch assignment, and on and on and on. It's not as simple as pushing {parameter, old_value, new_value} onto a stack. The simplest away around this is to store the state of the entire patch, but that's resource-intensive. And then there's the fact you completely glossed over, that it does in fact have to take the hardware into account. If you change the Drive parameter from 0.0 to 5.5, that may have actually been 55 messages to the Helix, 0.0 to 0.1 to 0.2, etc. Maybe the Helix doesn't have a simple message that can do that in one go. That's a bad example, because It probably does in the case of simply setting a parameter to a value, but there may be cases, like moving a block or changing an amp model, where it can't be done in a single message. My point is, we don't know the Helix hardware or messaging protocol, so we don't know what limitations may be there to complicate matters. Storing an undo stack locally is one thing, unraveling it into blocks that make sense to the user and packing those into messages that work with the hardware is another matter.
  8. I'm not sure if you're saying nope to me, but I paid $1200 for an open box Helix in minty shape (though it was listed as level 2; I could find no damage), and there are two more available at that same price at that store.
  9. No. You won't be buying a returned item without being aware of it, unless you buy from somewhere like eBay, in which case it's eBay so you know it's not "retail new in box" anyway. All legitimate stores label such products as "open box" (if it's just a return re-shelved) or "manufacturer refurbished" if it went back to the manufacturer to be checked out and repaired or "floor model" if it was a demo unit. "Open box" Helices are currently going for around $1200, and are a great way to get one with a little discount without the risk associated with used stuff on eBay. (Open box items will still have a reasonable return policy and potentially a warranty, at least from reputable dealers.)
  10. Some solid points, like the effects loops. And some good alternatives, like an SDK. The true power behind the iPhone / Android platforms is the app store, right? And Line 6 did something similar with the ToneCore platform, although that never took off. Hmmm, maybe I shouldn't mention that... :)
  11. Electro Harmonix is releasing yet another pedal in their line of <type>9 effects, the Mel9. If you're unfamiliar, check out the videos for the Mel9, Key9, C9, and B9. These things are crazy cool. Limited use, perhaps, but incredibly cool. And of course, they've got the older classics, POG, POG2, HOG, Micro and Nano POG...Pitchfork...maybe one or two more? I didn't submit an IdeaScale for the Mel9, because there are already several for other variations, but this is a line of pedals that I would pay to add on to my Helix. Yes, I would gladly pay for an add-on pack to a $1500 unit that gave me some of these effects. If there isn't the specific fuzz pedal you want on the Helix, you can substitute one of the existing models and have something similar. Same with reverbs, delays, and so on. But there's nothing that can get you the sounds of the Mel9, Key9, etc. Even the octaver in the Helix, which is pretty good, is just not up to the standards of the POG line (in my opinion). Glenn D has a decent organ patch, but he made an entire patch for that and it still isn't in the same league as the B9/C9. So here's my suggestion, which will probably get me mocked, ridiculed, and downvoted. (Is downvoting a thing here?) They have a head-start and they've already nailed this stuff. You can't catch up. So work with EHX, license their code, and sell add-ons for the Helix that contain these effects. They've got this style of effect down. They know what they're doing, and they've clearly got a generic code base that does the tracking for them to use in all these separate pedals. There are two reasons I would pay for this: 1) I don't think it would ever be possible to get it done without licensing the code from EHX. 2) They're very niche effects. Not so much the generic octave sound, but the B9/C9/Key9/Mel9 definitely are. It's a lot of development effort, even if you license the effects, for such a niche effect. (To be clear, I am not claiming it would be simple to implement these from the coding side, even if you license their codebase. I understand it's built on a different platform and would not be something you could just drop in. But there's got to be math and formulas and so on that you could pull out and refactor for your code, right? Or sub-contract their developers to work on your system...) Side note: having just sold my Boss SY300 to help fund my Helix purchase, I'm pretty disappointed in the synth effects on the Helix. I know the Helix can't compete with a $600 box whose soul purpose is to create synth tones, but you're still behind your old Line 6 models in this, and even things like the Zoom B3 have better synth sounds. It makes me sad. :( I really really want my $1500 multi-effects pedal to be the only pedal I use, but right now there are some areas that are lacking. Obviously, this is all subjective, just my opinion, and so on. You're free to disagree. Having said all that, I do love my Helix. :)
  12. It's good to know the ideas all get looked at regardless of voting. Line 6 has a lot of knowledge that we don't concerning market trends and feasibility and a dozen other factors beyond the "hey that's cool" factor that the average user (including myself) might vote on. A couple of my ideas got moved to Review status before they had a chance to go far either way (one was definitely going down anyway, but still), and I was worried they'd just float off into the void. They're both long-shots anyway, but still...maybe some day... Anyway, it's great of you guys to do that. I know it's a lot of work to sift through them all, but I think the direct connection between Line 6 and the customers is a very cool thing that not many companies would be willing to tackle.
×
×
  • Create New...