Jamstix 3 Information

[zerocrossing]

We are also working on a [b:da3e541d28]Groove Builder[/b:da3e541d28] that would process a MIDI or audio clip that represents a part (verse, chorus etc.) and feed information to the brain that cannot be done in real-time (due to need for look-aheads). This function will allow you to create grooves that fit specific rhythmic properties of your MIDI or audio clip better.

Hey...

what about the ability to input midi notes in real time to create a groove that simply loops, and then when the user gets the beat the way they want it, hit a button or PC change message that tells Jamstix to then base it's playing on that groove. It wouldn't have to work in real time as the beat could loop until Jamstix was ready to start improvising. Real drummers work this way anyway, playing a beat until they're comfortable with it and then branching out and experimenting.

Kudos to the new UI work, it's been one of my pain points with Jamstix. I'm probably more sensitive than most because I do UI for a living, but Jamstix always seemed to perplex me.

Also, great that you're thinking of supporting OSX. There's nothing like Jamstix for the Mac world and I'm thinking of moving back to OSX as my main audio platform and there's a big Jamstix sized hole in my life. You'd have a definite evangelist if you did a mac port for v3.

[drjee]

Hi,

congrats to the new GUI design, it really looks much better. It would be perfect if the icons would get some more attention and the fonts look less blury. But again, this GUI is a huge step up. thanks.

cheers, drjee

[tombuur]

I think Jamstix 2.5.1 fills my needs, but don't worry - I will upgrade anyway. Jamstix is the way to go. No need to spend a lot of time browsing through libraries of midi loops. I just plot in the basic rythm I want and let Jamstix add accents and fills. As for fills I just let it loop and press recompose until I got something that fits in the song at that bar.

The only thing I could wish was a little improved workflow when plotting my hits in the grid. Something like: crtl + mouse will delete a beat that is there, alt + mouse will add the most recently chosen kit part etc. This way I could quickly enter/remove kicks, snares etc. You can already drag a hit to another part of the grid, but dragging it outside the grid should result in deleting that hit ...

[Ralph @ Rayzoon]

The only thing I could wish was a little improved workflow when plotting my hits in the grid. Something like: crtl + mouse will delete a beat that is there, alt + mouse will add the most recently chosen kit part etc. This way I could quickly enter/remove kicks, snares etc. You can already drag a hit to another part of the grid, but dragging it outside the grid should result in deleting that hit ...

We added the following function in 2.5.1: double-clicking on an empty cell will add the last used sound and double-clicking a sound will delete it.

[Greg Dean (Archive)]

Lovin' the improvements on the GUI! With all these improvements, JS3 Is a definate upgrade for me. How many bars will you be able you edit at one time in the bar editor?

A feature that I would find really useful (if implementable at this stage) would be to have the ability to lock individual limbs (or areas of the kit) after JS has composed, so that if you've got the right kick/snare pattern you could lock those limbs and hit the compose button to recompose just the hihats without altering the locked limbs but still keeping them visible ( rather than just muting limbs in JS2 which removes hits from the bar editor). Hopefully this kind of limb locking would allow you to pick one style, JS composes your bars and then lock certain limbs that you like (eg. kick + snare), load a different style, then recompose just the remaining limbs (eg. hihats). Don't know if this is possible but i'm hope it is. Loving your work Ralph, here's to JS3 and beyond, my money's waiting for you......

[RhythmicallyChallenged]

Great news that V3 is on the way!

I'd just like to add my 2c about not being a great fan of the picture of the drum kit taking up so much screen real estate ... to keep everybody happy, would it be possible to add a "minimise" button to collapse the panel holding the kit to a "mini" view - perhaps labelled buttons only, or even off altogether?

Since I got myself a netbook and managed to get get Cubase working on it for small "travel" projects, it would be nice to be able to have a GUI that could be made fit on the standard 1024x600 resolution ... some products such as Renoise already offer this in the form of making two of the panels interchangeable when running at lower vertical resolutions, but default to full view on 1024x768. Another variation is Samplelord, which has multiple views of different sizes, although not quite fully "skinnable".

[rcraig42]

Lovin' the improvements on the GUI! With all these improvements, JS3 Is a definate upgrade for me. How many bars will you be able you edit at one time in the bar editor?

A feature that I would find really useful (if implementable at this stage) would be to have the ability to lock individual limbs (or areas of the kit) after JS has composed, so that if you've got the right kick/snare pattern you could lock those limbs and hit the compose button to recompose just the hihats without altering the locked limbs but still keeping them visible ( rather than just muting limbs in JS2 which removes hits from the bar editor). Hopefully this kind of limb locking would allow you to pick one style, JS composes your bars and then lock certain limbs that you like (eg. kick + snare), load a different style, then recompose just the remaining limbs (eg. hihats). Don't know if this is possible but i'm hope it is. Loving your work Ralph, here's to JS3 and beyond, my money's waiting for you......

You can do something like that right now by loading just the hihat (or whatever) aspect of the other style into the brain after deleting or muting the Hihat aspects of the style already there.

It's in the Brain Menu called "Extract from other style"

[Klemperer]

The new things that will be added to JS3 sound very very good to me. I think I'll be quite happy with the additions, and some things mentioned here are just minor gripes for me. For example, as long as we can zoom in and out of the timeline, I am not worried much if it will be too big or not big enough for my screen or something. Sometimes we are a bit spoilt and forget what the strenght and great things about JS are.
What I love about Jamstix since JS1 is the exciting way you get a drummer into your homestudio, and for me it is a tool to accompany AND to learn a lot, like a never ending process.
So, for example the addition of even more drummer models and stuff like that is really superb, you will learn to find out what else is possible, and how it affects your songs.
Anything that lets the uniqueness of JS even more, well, shine, is what will surely be a pleasure for all users, like JS2 already is.

[andrew_k]

I'm so glad the GUI is being remodeled - thanks so much Ralph! When I first saw Jamstix (v1) I took one look at the GUI and dismissed the software altogether. I superficially judged Jamstix's capabilities by its appearance, nearly missing out on one of the best pieces of music software I've ever used. The new GUI is definitely a step in the right direction. Anyway here's my 2 cents on a few things. Please note I am perhaps being a little outspoken in my opinion here (and it is all just opinion). I hope I'm not over stepping the mark:

1. I believe a UI should present the essential features required by the user in the most direct way. This means the eye should immediately be drawn to the UI elements that access the core functionality of the application. ie. what does the user primarily want to do, and how can we present that functionality in the most intuitive way possible? A good user interface should make it apparent to the User Manual phobic (those that just won't read the darn manual!) where they should start and what they need to do to access the core capabilities of the software. Anything that doesn't directly contribute to this is really clutter. For instance, as pointed out by someone else, the large drum kit graphic, while certainly great to look at, is essentially ancillary to the core midi creation function of Jamstix. However rather than reducing its size maybe you could move it to its own tab: it really isn't part of the core purpose of Jamstix and, hence, is essentially a kind of distraction in its current position.

2. The large diagonal tab buttons at the top possibly take up too much real estate. This along with the actual design of the tab buttons means the eye is drawn to them rather than the panel at the bottom where the real work is done. The diagonal lines of the tab buttons perhaps contrast too greatly with the curves on the rest of the UI, creating a sense of clutter and/or tension. As others have pointed out the fonts perhaps aren't the most legible. More opinion here, but you could consider using simpler buttons that let you change tabs without immediately drawing your eye to the top. The design of these buttons should be in keeping (ie. similar) to the design of any other buttons in the UI. This means the user can immediately identify something they can click as it has the same design as all other 'clickable' UI elements.

3. There are quite a few button styles in the bottom panel. The UI should help inform the user concerning the usage of an application. As noted consistency in the design of UI elements aids this, hence using just one design for all buttons or clickable elements could be the way to go. The use of explanatory text displayed on mouse over as in the Jamstix 2 UI is a brilliant idea that could further inform the user.

4. The curved elements surrounding each GUI panel (the kit and the bottom panel) have a couple of straight lines in their corners. They also have a series of little notches in them. Maybe you could consider removing all these as less lines equates to a cleaner, less distracting GUI.

5. The bottom panel, where the real action occurs, has too many fonts, too many lines in the grey areas and no direct indication for the user manual phobic where they are to start. With regular Windows applications the use of standard menu layouts and toolbars means it takes users less time to get to grips with a new piece of software: the UI elements are essentially the same from application to application. With something like Jamstix, where you are both presenting entirely new functionality and a non standard UI it is vital the interface provide some clue as to how to use the application. The questions to ask are: Where does the user start? What do they need to do? What do they need to do next? How do we make it apparent to the user what the purpose of this application is and, more importantly, how they access that functionality? None of these are easy to answer but nail them and you not only have a fantastic piece of software but also one that is relatively easy to use (and a good looking one to boot!).

[Susan G]

Hi Andrew-

All excellent points, and I agree completely! In particular, the sizes of the bar editor grid and the drum kit graphic could be switched and I wouldn't mind a bit. It's true that we can get to the drum editor through the kit, but there are other ways that could be handled (including the "classic" buttons approach -- not sexy, but very practical and space-conserving -- as a User option).

IMO it would be best if the Brain controls and bar editor panels were the biggest GUI areas, and maybe even floatable/User-resizeable. I've always felt cramped working in the bar editor (esp. trying to decipher those tiny icons!), so even the rough draft represents a welcome improvement. And I can't really see any good reason to continue forcing scrolling on the Brain.

This is such a great app already, and with some GUI improvements along with whatever Ralph has up his sleeve in terms of functionality, it will be *crazy* great!

Thanks-

-Susan