Sequencers
Hi all,
all this talk about sequencers an guis made me want to particpate so I patched up two sequencers with some eye candy :a matrix sequencer with changin color toggles (thanks Malestrom) and simple note sequencer with size-changing canvases (thanks Addisaden and again Malestrom).
Hope you like it
B.
Thanks Malestrom, good idea,
I thought it would be nice to drag the canvas and I didn't think of using a vslider behind ... now it's done 
I also replaced every floats dealing with notes and velocity by integers .
I've got a question though :
when I work with a seq like this one, and you plug it into a basic synth (takes in inlet a note and a velocity, both go into a stripnote) I need each (n-1)-step to have a velocity set so that the n-step produces a note. why is that ? how can I make it work normally ?
It's because you have them triggering backwards. It's actually using the velocity of the previous note. You should use a [t f f] out of the [mod 8] to enforce the right order. Also, it makes more sense to have the note come out the leftmost outlet and the velocity to the right of that. So velocity is sent before the note (right-to-left order). That's how [noteout] does it and what other objects like [stripnote] and [poly] expect.
Hi,
thanks Malestrom for the crystal clear explanation, I had never truly understood what was the point of triggers before that, this is a good didactic example (for me at least).
so now the sequencer has 16 step and is prettier than ever, I added delay parameter for each step and a glide effect (ie a line from this value to the next one).
I still have a little pb with the counter that is a bit late. I put a trigger after the mod object and the righmost inlet is used to control the lightening of the concerned step, neverthless the counter is still a bit late.
does anyone have an idea of the pb ? any suggestion to improve this seq or optimize the code ?
What do mean about the counter being late? Where do you see it being late?
A few things:
You don't need all those [delay]s with the velocities. You could instead just store them in an [f ] and send the delayed note values through a [t f b]. Then you can use the bang outlet to send out the velocity along with the note.
I'm not sure I understand your glide implementation. It looks like your just sending a bunch of gradual note-ons. I don't think most synths would interpret this as a glide message. You might want to think about just having another outlet sending the glide amount. I think that would be more flexible for someone to tailor to their synth or patch. But the way you have it, you should trigger the glide time BEFORE the notes.
Also, I think you should make the leftmost outlet of trigger update the gui. Let the musical stuff happen first, save the gui for last.
And make the handles on those sliders the same color as the background. It's distracting to see them, and the user doesn't need to. The [cnv]s do the same job, anyway.
Finally, (and this is about as minor as it gets, I know) as much as I like variable width fonts, I think you run the risk of your gui looking differently on other OSs. It's uglier but safer to use the default mono font.
Hope that helps.
Well it's not the counter that is late it's the Gui that illustrate the counter (the row of sixteen toggles at the top of the sequencer window which turn pink when you launch the metro)
Thanks for your advice, I'll work on that. It should optimize performance.
For the glide, I want to be able to use this sequencers with synth that do not have a glide parameters implemented that's why I used this option. For me it's a midi-glide-effect if such a thing exists.
I've already encountered the pb of the fonts with gui on several oss, I didn't relate it to be the font so thanks for that, I'll change this in most of my patches as I intend to share them.
Cheers.
@BerengerRecoules said:
Well it's not the counter that is late it's the Gui that illustrate the counter (the row of sixteen toggles at the top of the sequencer window which turn pink when you launch the metro)
This might just be that you have so much gui going on. Pd's gui is not very efficient, so the more there is, the less responsive it will be. I haven't tried to run any audio with it, but the sliders seem to respond to my mouse clicks okay, though. (first gen MacBook Pro)
For the glide, I want to be able to use this sequencers with synth that do not have a glide parameters implemented that's why I used this option. For me it's a midi-glide-effect if such a thing exists.
Have you tried it, yet? I ask because I can only imagine this working on a monosynth with no retriggering, which seems like an unlikely scenerio for no glide implementation. And even then it wouldn't sound smooth.
hey its me
doing a bit of advertising
for my own sequencing
pd redefining mathematics |expr fact(0)|==0
p.s. a glide function is a great idea
can't remember what else i wanted to add to my sequencers
the smooth sliding canvas looks great too but i try to make the gui use as less cpu as possible
so i update as rarely as possible using only really necessary changes and speedlim
pd redefining mathematics |expr fact(0)|==0
Hi Guys,
thanks for maintaining this thread alive,
@slur : be my guest , your sequencers seem great, it sure will be preferable to use yours when dealing with a great number of seq, mine is mostly for show off
@maelstorm : well I have done all the changes you mentioned. For the trigger I only used one select for all the note events.
so it goes like this : after the select you've got a delay for each step then a t b b b that triggers rightmost = glide , middle = velocity, lefmost = pitch, each of those bangs a float with the value in it.
I've attached a new version with a synth to test the glide function.
I might work on the same kind of gui and add the possibility to control other stuff such as FX or synthesis parameters step by step (using also a glide function to control morphing of the sound), using a default 0-127 h-slider as those made in the abstractions. Any comments about this ?
Oops! Looks like something went wrong!
