#263

Unfortunately, it’s not that straightforward. Buffer playhead is a Phasor which doesn’t have an easy way of notifying the synth about reaching end of buffer. I’ve wrote an UGen for doing that called TrigPhasor, which comes with matron, but haven’t yet adapted the engine to use that.

1 Like
#264

i’d just do it in on the lua side. Glut reports the position in the buffer using a poll. you want to call stop_voice(n) automatically when its corresponding phase_<n> poll nears 1.0.

3 Likes
#265

that could work, but 1) voice will continue playing from the start until it fades out and 2) the poll frequency is not that high to avoid restarts between polls.

1 Like
#266

Sorry, just saw this! The notion of PPQ in beatclock is split between ticks_per_step and steps_per_beat. Depending on what you want to do, increasing one of those properties (of the beatclock object in your script after you create it) might be the solution. If you want a clock that’s faster than the external clock ppq, though, you might need additional clock-multiplication logic. Or reducing ticks per step might be what you need to get a step clock that’s faster than the external clock.

#267

Is it possible with softcut to read a sample’s amplitude vs time - so it could be mapped out on the screen or grid?

#268

currently it is not, and it’s completely doable but also kinda non-trivial (decisions to be made.) discussion here:

i’ll bump that issue as there have been some adidtions to infrastructure that would make it easier.

1 Like
#269

true. hm.
then, @Tyler, i dunno. the granulated playback position is a Phasor ugen. this guy is always looping, so you would have to make significant changes to the synthdef: don’t use Phasor, or latch its output, or automatically close the gate at the appropriate time - which would be: when (1 - pos) / (pos rate) >= (envelope release time.)

#270

@zebra admittedly, I didn’t look at Engine_Glut.sc before making my comment, I made the wrong assumption that it was mostly reliant on the buffer class. Is it possible for the Phasor ugen to be modified within the engine?

#271

The current discussion of how to make one-shots work is well over my head (at least as far as implementation is concerned), but I appreciate you folks thinking about it and sharing ideas :slight_smile:, so thanks!

#272

It’s not possible to modify Phasor behaviour in sclang code. I currently think that the best solution for one-shots in glut with the current engine design is not depending on buffer length and position, but having fixed time for attack and decay per-voice, e.g. as soon as a voice is toggled - fade in and then fade out immediately.

3 Likes
#273

can you attach the script so i can see the full code?

#274

Of course:

#275

this is maybe a more general coding philosophy question, but those who feel like they Know How To Do This, a question:

how do you decide when a feature is workable and when something should be redone/“cleaned up”?

i’m working on a little sequencing script and every time i get a function actually working correctly i feel like I need to redo the entire thing from scratch because i’ve used way too many variables/lines/arguments for what i actually need. and maybe this aspect of this function should be its own function and there must be a way to do this with less for loops and…

i’m on rewrite 5 of my script and have just gotten the behavior of encoder 1 to be 100% what i want. do i start on encoder 2 or do fix i the 100 line “modulate_scale” function with 4 loops and 12 variables that i had to make to get it there.

two competing schools of thought in my brain:
1- if it works, it works
2- if it later turns out not to work, it will be way harder to identify the problem with these monster blocks of code, so i should just start over now…

1 Like
#276

don’t hesitate to refactor at any time, for reasons of:

  • performance
  • readiblity
  • orthogonality
  • repetitiveness

Know How To Do This

ha! ha…

8 Likes
#277

I would recommend my friend tef’s blog as a good approach https://programmingisterrible.com/post/173883533613/code-to-debug

(he used to work for me - and taught me a lot)

From a personal point of view - you are going to have to maintain this code. You are very unlikely to come back and tidy up (if you are like me - mind you at work I have a team of engineers replacing the code I wrote in the first half of the companies life but that’s a luxury I don’t have for my music code).

The balance is between highly polished code that never gets run because you are polishing it and a pile of poo that makes wonderful music. I’d suggest the ideal place is when you come back to the code in 6 months time you aren’t considering building a time machine in order to visit past-you and teach them a lesson or two…

5 Likes
#278

hey, I’m noticing some weird behavior from screen.pixel – one of the weirdest things is that it always seems to be rendered underneath (i.e., painted over by) screen.lines. Is that intentional?

#279

oh, maybe overlapping pixels influence each others’ levels? (i.e., screen.level() is treated as alpha rather than as different shades of gray)

#280

Has anyone done anything with HID yet?

tried to get an USB apple keyboard to do stuff, but it’s barfing at me - it enumerates as 2 devices (prob because of the built-in hub?) and then gives me error: double free in device_hid.c a bunch of times on disconnect.

hid.lua script in dust/scripts/study seems a bit out of date. :frowning:

#281

sadly the HID study fell out of date but i’ll check it out for you. shouldn’t be difficult to get a keyboard reading. i did make a gamepad demo for the original norns release video.

1 Like
#282

Exclude certain parameters from loaded on parameter set loading?

I’d like to adjust tempo on the parameters page, but when I load different parameter sets, I’d like the tempo to not change, but remain on the last value I set for it. Or in slightly other words: Is there a way to make a parameter appear on the parameters page, but attaching a flag to it that excludes it from being changed upon loading a parameter set?