RAYZOON

The one thing I would like to see in JS3 is a streamlining of the song save process. At the moment we have to stop the song, click the drop down menu, click on the save song option, navigate to the present song title(as the file name box is always blank), click on the present song title and then click on the save box. That's six operations just to save a song in JS at the moment. If you save a song, for example, ten times in a session that's an extra 50 mouse operations compared to saving, say, the host project which can be accomplished with one operation; a simple Ctrl+S and can be done on the fly without stopping the session workflow. I appreciate that the host and JS maybe has to be stopped for technical reasons before song saving and there's no way round that. I would like to be able to stop the host and Ctrl+S to save the JS song. No drop downs, opening windows or navigation just one key command. Real quick. If it's possible to save on the fly then that would be good. Also to have all the usual file save, opening keyboard options available. Having a function that would give names to the restore points rather than just a time would be extremely useful too.

I may be doing things wrong and there maybe a better way to save songs. If so disregard all this.

nightscoper

Just a quick note, the jamstix info usually does save with the host project, saving the song from jamstix is more of a backup or transfer utility than anything else.

rcraig42 wrote:Just a quick note, the jamstix info usually does save with the host project, saving the song from jamstix is more of a backup or transfer utility than anything else.

Sure. I understand that.

nightscoper

Given that JS2 automatically saves with the host, what exactly are you using the descibed save operation for?

Ralph [RZ] wrote:Given that JS2 automatically saves with the host, what exactly are you using the descibed save operation for?

For saving the JS songs as a separate entity , obviously. The way I work is to get the song mapped out into parts like most folks. I like to save that as a draft and then move onto various other versions, different drummers, styles, tweaks. etc. I save them all often and end up with a few versions to choose from. Also I find I always have to have another safe version as JS sometimes behaves in extremely strange ways when, say, copying parts about. Such as playing fills where they shouldn't be and not allowing me to mute accents and fills for some reason. So I have a safe version and a working version in case thing go haywire. I'm constantly saving the JS version before any major copying operation.

If you're going to have a JS song save function separate from the saving with the host feature it would be nice to have it as simple as possible for those that use it a lot.

What do you think of the capability of having names for the restore points, Ralph?

nightscoper

We could preload the current song name in the 'Save' dialog to take away the need to browse for the file. We could also split into 'Save' and 'Save As'.

I'll look into naming of revisions when the disk icon is clicked.

Ctrl-S and similar keyboard shortcuts are not possible since some hosts intercept keystrokes so it would be a slippery slope.

Ralph [RZ] wrote:We could preload the current song name in the 'Save' dialog to take away the need to browse for the file. We could also split into 'Save' and 'Save As'.

I'll look into naming of revisions when the disk icon is clicked.

Ctrl-S and similar keyboard shortcuts are not possible since some hosts intercept keystrokes so it would be a slippery slope.

Thanks, Ralph. I think names for restore points would be great. I also appreciate that I am but one user amongst a multitude and may do things in a less than optimal way. Also that you have much to do and time is short. Looking forward to JS3, count me in as always.

All the best.

nightscoper

charly1310 wrote:@hitch & spitfire: +1

I have to agree here. To me the new GUI looks terrible. It's certainly a little more modern than JS1 and JS2, but it doesn't do away with Jamstix initial design flaws. I still see too many different fonts, too many bold borders and too tiny controls. In general the GUI looks very cluttered with many different visual styles for objects all cramped together. There's no sophisticated design concept behind it, other than trying to look "cool".

Although you said that the GUI design is still work in progress I recommend to totally scrap that design and start from scratch. Not only from a visual point of view, but also for Jamstix' operability/usabilty concept. Right now I can't see any workflow enhancements represented by the GUI and I think that's where the whole issue starts.

Sorry for being so critical, but I really hope you reconsider the current design concept, because Jamstix deserves a much more professional GUI than that to keep up with it's outstanding core functions.

Cheers,
bM3w

+1

Hi Ralph, hi all.......

I don't post a lot, though I do make frequent visits to this forum. What's been going on in this thread however, makes me want to open my mouth for a change and offer a few words.

Firstly - that all JS users are a polite crowd when posting and seemingly well into their music. Fantastic! Also, that they all show a keeness to contribute to the continued evolution of this great piece of software. Also good.

Which leads to the second point - that its creator, Ralph, is a very rare breed amongst software developers, that positively encourages his customer base to write in with ideas regarding the creation of the next version and really does listen.

So, what's the deal?? Well, there's a dangerous fine line between Ralph requesting and we offering suggestions for the next version and Ralph posting a "this is how it's coming along" graphic and we hitting him with criticism (although clearly intended as positive criticism), to the point that some are suggesting 'better to scrap it now and start over, even if it means delaying the release again'.

The talk has been of functionality over eye-candy; greater ease of use with another specific drum package; how much screen real estate; top 10 actions accessed by single clicks etc.....

Any suggestion can prove useful, but some simply impractical or unrealistic or too subjective. For instance, how many programmers must Ralph have by his side to test drive JS with every other drum package out there. That screen shot of Zebra, is to me, a real put-off. But this is another story.

The reason I'm writing now is to urge Ralph NOT to post any further "work in progress" screenshots because the danger is, that no matter how well-intentioned we users are, the comments from those who are not happy with JS3 progress might delay its already delayed release or dent Ralph's enthusiasm. This would dissapoint those who are looking forward to it already, or devastate all of us if there was no JS beyond version 3. (I'm guessing Ralph is quite a strong-willed guy however).

In short, all the suggestions you nice people are coming forward with now, following Ralph's posting of JS3 screenshots should be aimed at JS4. What Ralph is doing with JS3 right now, is in reponse to your comments following JS2 release. He's already had to overcome a hurdle, what with Scott not being able to finish the GUI (and I'm sure many other hurdles).

What Ralph needs now is louder cheering to get him to the JS3 finishing post for November and certainly by Christmas. Try and focus on the stated improvements JS3 holds over JS2, keep making loads more music with JS2 in the meantime and yes, keep posting your thoughts on further improvements - but direct them now at JS4.

So there's a helpful suggestion Ralph - can you start up a JS4 suggestion thread right now, so that the remainder of this thread can be taken up with bloody loud cheers of encouragement.

Oh.... and P.S. Ralph - Can your graphics guy just spend 3 minutes as I did before writing this post, to go into Photoshop and select the chocolate brown facias in your GUI, use the hue slider to change the brown to a warm grey as well as turning down the saturation and then lighten those areas to get a warm silver finish. (More like the initial Scott Kane version). The choc brown doesn't look too good and too many colours. More understated chic with silver.

(OK guys, OK - this is only a 3 minute change I'm suggesting, not a 3 day code re-write).

I'll send you what I've done by e-mail as I don't know how to add the image to this post.

Hope none of you 'posters' feel got at by this. It's all good intention. Cheers.........

I like the gui overall. My suggestion would be to add another tab that is a bar editing tab. That way the bar editor and navigator would be the primary focus and could be made much larger. the song part could be made smaller and the bar navigation moved up and to the right. then the bar edit portion could be wider and taller...so my old eyes would not have to work so hard.

I'm looking forward to the upcoming release.