Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Gates & Triggers script #307

Closed
wants to merge 7 commits into from
Closed

Conversation

chrisib
Copy link
Collaborator

@chrisib chrisib commented Oct 21, 2023

Adds a new script to convert gate signals into rising/falling edge triggers & convert incoming triggers into variable-duration gates.

@chrisib
Copy link
Collaborator Author

chrisib commented Oct 22, 2023

Commit 327c3cc has been moved to #308 instead to keep the scope of this MR to just the new script.

@mjaskula
Copy link
Collaborator

There is some related (reversed?) functionality in PR #260, but it hasn't been reviewed yet. Part of me wonders if there might be advantages to combining the functionality into a single script, as they are spiritually similar.

@chrisib
Copy link
Collaborator Author

chrisib commented Oct 22, 2023

Ah, I hadn't gone through open merge requests to see if there was already something that implemented this. I just went through main. I'm not surprised someone beat me to it; it seems like a pretty obvious utility.

Reading through #260 it these stand out as the biggest differences:

  • the 260 version has a self-clocked/LFO mode
  • the 260 version adds an optional delay between the trigger and the start of the gate
  • my version has the ability to generate manual gates via the buttons
  • my version converts incoming gates to rising & falling edge triggers (260 just goes trigger -> gate, not gate -> triggers?)

There's definitely a lot of overlap in the trigger-to-gate functionality, but I'm not sure how to reconcile the other differences without sacrificing some of the functionality (e.g. losing the manual gate buttons to add UI interaction, removing the LFO feature in favour of two independent signal channels).

EDIT
I wrote this script with the EuroPi LC in mind; something small, fairly single-purpose, that didn't need a screen to explain any of the mode options or controls. The multi-mode/overloaded knob feature of 260 runs counter to a lot of that.

After thinking about it a little more though, we could do something like this to combine them:

  • leave the din/cv1-3/b1/k1 signal path the same as it is now; this covers the gate-to-trigger and trigger-to-gate functionality with a manual trigger
  • implement the clock/LFO mode using k2 to control the clock speed, k1 pulls double-duty to set the duty cycle of the LFO square wave. cv4 is the LFO wave. cv5-6 are rising/falling edge triggers based on the LFO rate & duty cycle
  • b2 and ain are unused in this configuration. ain could probably be used as a CV input to control k1 or k2. Maybe b2 changes what ain is controlling? (Using b2 for this would break the no-screen EuroPI LC design goal though since you'd need a scree to indicate what mode you're in.)

I don't hate this, but I'm currently using the 307 version in a patch and really enjoy having the two independent channels. Being able to convert two separate LFOs into rising/falling edge triggers is convenient for generative patches.

The LFO feature from 260 is neat, but it doesn't feel like it fits with the design goal of a gates & triggers program. It's useful, but it's also its own thing and trying to shoehorn both of them together into the same program feels like it sacrifices more than it adds. If I want clocks/LFO signals I'll use the Harmonic LFO or Pam's modes. If I need to process gates & triggers I'll use G&T. I struggle to think of a time where I'd need both at the same time.

@chrisib
Copy link
Collaborator Author

chrisib commented Oct 28, 2023

I've been thinking about the comparison between the two G&T-like scripts some more this week. As nice as the two-channel mode is, I do find myself wishing there was CV control over the gate length too. I'm considering an I/O overhaul where the new version would work like this:

  • DIN: the primary input, processed exactly like it is now
  • CV1: gate output; rising edge is triggered by DIN, gate duration determined by AIN + K1 + K2 (see below)
  • CV2: start-of-rise trigger output if DIN is a gate signal
  • CV3: end-of-fall trigger output if DIN is a gate signal
  • K1: primary gate length input. Non-linear scaling from 10ms to 2s duration
  • AIN: CV control over K1
  • K2: attenuator for AIN
  • B1: manually mimic the DIN input signal

The gate duration would be calculated by sending K1 + AIN * K2 into the duration-calculation function. This would let you use CV to increase the duration beyond 2s if both all 3 inputs are high. Turning K1 all the way down means the gate duration is determined wholly by AIN * K2.

This leaves CV4-6 free for some new features. Haven't thought this out all the way yet, but I was thinking:

  • CV4: End-of-fall trigger for the gate output on CV1
  • CV5: Toggle output; initially low, changes every time the input signal changes
  • CV6: End-of-fall trigger for CV5

B2 is also free, since it's not manually triggering the second set of gates/triggers, so it can be used as a manual toggle input; it would invert the state of CV5, but would not affect CV1-4

This brings some more of the functionality from #260, while also making the script a little less specialized and opening up some CV-control options. The LFO/clock feature is still absent though; are we okay with that feature not being reimplemented here?

Before I get into the nuts-and-bolts of rewriting the script to add the features above, are there any opinions? Does something seem obviously missing or out-of-place?

@chrisib
Copy link
Collaborator Author

chrisib commented Oct 29, 2023

I've made the proposed changes above in #309, along with some other updates & improvements.

If that one gets approved I'll close this one, as it's probably redundant now

@mjaskula
Copy link
Collaborator

I've made the proposed changes above in #309, along with some other updates & improvements.

If that one gets approved I'll close this one, as it's probably redundant now

@chrisib You've though about and used these scripts more than anyone else recently, so I trust your judgement on the best way to move forward.

Just to be clear, there is not requirement from me to borrow any functionality from the #260 PR. I just wanted to point it out to you as another source of ideas, and work that the community has produced.

I say Focus your energy on the single script / PR that is the most useful and whose features make the most sense to you and leave the rest behind.

@chrisib
Copy link
Collaborator Author

chrisib commented Oct 31, 2023

Fair enough. I think I'll close this one and shift efforts to #309. As convenient as the dual-channel mode is, I think the CV control in the other version is ultimately more useful.

@chrisib chrisib closed this Oct 31, 2023
@chrisib chrisib deleted the g-and-t branch February 9, 2024 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants