i almost finished my drum machine for the organelle, it’s really fun to play with your creation (my first) i had fun implementing step jump functionalities yesterday,
now for the cherry on top i want to make nicer visuals, for instance when changing values i want to show a slider instead of just the number, i experimented with /oled/gBox yesterday, took a while with trial and error to find out what the params did but it turned out simple: [/oled/gBox ?? top left width height (1= add, 0 = remove].
simply asking how would you want implement that, i was thinking maybe using gLine and having one line per height of the slider and fill the area, but doing for-loop logic in pure data i find cumbersome
I’d create the box. Put the line when you want it, fill the box with 0 and then put the line the next place you want it. No loop I can think of, just a trigger to fill the box and then pass some variable to put the line when a value changes.
OFAM has sliders if you want to see how someone else has done it. Not to say that there’s not a better way, or better looking way to do it.
thanks for the replies, i’ll definitely check those.
in the meantime, i did try to implement my own solution using /oled/gLine, what i did is that i drew a horizontal line (slider knob) at the correct value that slides up and down over a vertical line (sort of a cross style fade icon). It worked well, but it made my whole patch laggy, if i disconnect the /oled/gLine message, everything runs fine.
so i guess it’s the gLine refreshing that’s causing the lag.
in my patch every time the slider value changes, the line is undrawn, then redrawn at the correct new location, i also have a knob value smoothing algorithm so that if i quickly turn the knob from 0 to 127, then the drawing function will smoothly pass through all the values without skipping any, the actual values being drawn are between 22 and 37 because my slider only uses 15 lines in height so no need to redraw the same line twice unless the value changes (in the 22 to 37 range).
perhaps i should remove my knob smoothing algorithm so that the slider animation is less smooth but this would cause less lines being drawn when values are quickly skipped.
also worth noting that my lines are actually 2 lines (for thickness).
i could maybe also dump some of that on other cpu cores ? but i’ve never done that i’m not sure how that is done.
i couldn’t find much documentation on cpu core implementation on the organelle and the all the /oled/* function (had to find the params definitions through trial and error). At least for /oled/gLine it seems to be (bang (any value), x, y, width, height, 1 = draw or 0 = undraw).
thank you, i just realized this is the patch from the other thread i asked a question and had completely forgotten about it ! now i can’t wait to get home and check it out
this line helps so much haha, first time i saw that patch it was all foreign to me, but now i have an idea of what’s going on and i realize how valuable it is, thanks
I was recently working on implementing faders for an upcoming filterbank patch… this is purely the visual interface I have so far in case you want to take a look. The first 12 keys select a fader, and knob 1 changes the level. I would still like to implement some kind of value comparison per fader in order to prevent abrupt changes, but the general outline is in place.
i work 9am to 5pm, then spend 6pm to 1am on it every night haha, can’t wait to share it. I have three knobs that do nothing, i could perhaps leave them doing nothing and gather suggestions, at least one of them is going for a reverb send though but i don’t want to use freeverb, i feel it’s not the best for drums, i don’t think i will implement my own reverb as it seems it would take me at least a week to do it well, any suggestions for percussive-friendly verbs i could import ?
oh cool thanks for that, i have somewhat solved my lagging issue by making the slider animation slower and using less lines, but i had to sacrifice some of its visual appeal
