The stretch feature is not quite what I imagined. I thought it should stretch the sequence, and maintain the pattern but in a shrinked/expanded form. Perhaps a bit tricky.
Ah, think I will pull the relevant code into some other model, because the ability to distribute X notes over Y lines is definitely useful
The blanknote feature is useful for two practical reasons that I can think of:
You want to overlay a second generator into the same column, for instance putting low velocity hi-hats into the same column as high velocity hi-hats.
You want to mute (erase) notes from a generator when they are clashing with another generator (i e, silence kicks whenever there is a snare). This would then be done by duplicating the snare generator, and outputting it to the kick column with blanknotes on.
That makes sense, the challenge is really how to express it without turning everything into a complicated mess
Nevertheless I am liking this generator! I hope xstream will be developed and that the GUI could be made even more usable.
Actually I did (inspired by our discussion) undertake a major refactoring of the UI class in xStream. It was a monster, about 5K lines of code.
Now it’s much more manageable. Still need to do the “tab” thing, but this class needed to be sorted out first
But I used math.floor and you used math.ceil (or the other way around), rendering delay values being one step off. Maybe your way is the correct one and I should fix this in my tool.
That makes sense, the challenge is really how to express it without turning everything into a complicated mess
Yes. GUI grouping would help a bit. I’m thinking something like this:
Top group (euclidean sequence, minor cycle):
Steps
Pulses
Offset/rotate
Reverse
Cropping/padding
Stretch
Next group (major cycle):
Cyclelength (usable for restarting minor cycle at any place, i e some things maintain polyrhythm over longer time)
Offset/rotate (just for flexibility)
Next group (various settings):
Blank notes
Don’t overwrite with blank lines
Invert hits/non-hits
Last group:
Instrument
Velocity
Column
Actually I did (inspired by our discussion) undertake a major refactoring of the UI class in xStream. It was a monster, about 5K lines of code.
Now it’s much more manageable. Still need to do the “tab” thing, but this class needed to be sorted out first
Great to hear that you’re putting effort into this tool. It’s very potent.
Also, yes to your other suggestions.
Making xstream a streamlined and user friendly part of workflow when generating patterns would be huge. Even more huge than Renoise having a piano roll I guess that would call for a new pasting principle alongside live and TRK, that would fire any time an input track is updated.
I just put out the new version (1.45). Managed to release our in-progress euclidean generator - oops
But most importantly, I’ve had a bit of time to think about the tabbed arguments implementation.
And I think the best way to structure this is to think in terms of the “args” becoming a multidimensional array.
So, imagine for example my sequencer model - it has four notes, four volumes, four duplicates of pretty much everything.
What I would want when accessing those values would be something like
args.pitch.a
args.pitch.b
args.pitch.c
etc.
Or alternatively, I could organize my arguments like this
args.a.pitch
args.a.volume
etc.
In either case, I would create arguments while making use of a basic dot notation syntax.
The UI would then organize the arguments panel accordingly,_as well as_providing the ability to sort the entries
Because of the way it’s stored we can control the order of keys - something you normally can’t do in lua tables.
Not sure if having tabs within tabs will be necessary - it will certainly make the code a lot more complex. Try to consider if your example above could be structured to provide everything needed in a single tabbedlevel? We still need multiple generators, right?
It would be nice to have a tab for each generator, but also the ability to group arguments (you know, just the subtle graphical box thing to make the gui more user friendly).
Maybe that would be difficult to make? I’d imagine something like
I guess that would call for a new pasting principle alongside live and TRK, that would fire any time an input track is updated.