Preon01 to play -> out01 etc

I could swear this was discussed but I can’t find it.
Would it be a lot of change to do something like this, where preon is still randomly chosen, but the out.wav file is based on the same number file used?

Secondly, how about the same hum plays until off/on. So if multiple hums exist, a random hum gets chosen and looped until next off/on instead of randomized when file’s done playing.

I don’t have time at the moment to play with the code but maybe someone feels like tinkering?

1 Like

The first one i understand, but why would you want less random hum sounds?

Juansith reached out to me about it. Basically, he was looking to have multiple hum versions in a font as a way to give variety to the experience, but to remain constant within the same ignition session. The next ignition would be the change, thus avoiding the need to make the hums fade out of and into a neutral sound so that they would loop cleanly into the next hum. Not sure I can explain any better than that.

It sounds to me like Juansith is trying to make “alternate versions” of a font creation, meaning the font theme itself is the same through out the entire fonts wav file lists…but you get a different version of it every time you ignite the saber (while the same font is active). So igniting a saber once will pull only out01/in01, only use hum01, and perhaps assign only swng05-swng10 in this instance. But the next time you ignite this same font…now only use out02/in02, hum02, only swng01-04…etc…

Is this what he is asking for?

1 Like

Assuming something like that, yeah.
To me, preon matching the out regardless of anything else does make sense. Multiple variations of ignitions is cool. Maybe even a step further and we could go into using USER defined effects to specify blade preon effects to match as well. In essence, having EFFECT_PREON1, EFFECT_PREON2 etc…
Same could be said for in.wavs->pstoff.
@profezzorn, would adding more than 5 USER slots for effects be no big deal?

I think the hum idea stemmed from trying to have ignitions blending into hum in a more controlled match.
However, that really could just be done by fontVer1, fontVer2 setup in subsequent presets so :man_shrugging:

I’ve been thinking for a while that we should have per-effect settings. This feature seems like a good reason for it. Basically we could have something like this in the font config file:


Missed this. It seems like maybe the groundwork has now been laid for this, just a bit more code to make the hum remain non randomized until next ignition?

SInce the hum → hum transition is gapless, setting it as linked should make it use the same hum file over and over again.

Isn’t this already linked ? ( in effect.h, yes?)
EFFECT2(hum, hum);

Well I took a crack at this, made some pretty copy-cat code of the SetPaired stuff in FontConfigFile class, edited effect.h and the font config.ini…then when it didn’t work, realized hum is not going to fall under Effects, so no dice.
Any hints?

First guess:

   for (Effect* e = all_effects; e; e = e->next_) {
      char name[32];
      strcpy(name, "ProffieOS.SFX.");
      strcat(name, e->GetName());
      strcat(name, ".");
      char* x = name + strlen(name);

      struct PairedVariable : public VariableBase {
  Effect* e_;
  PairedVariable(Effect* e) : e_(e) {}
  void set(float value) override { e_->SetPaired(value > 0.5); }
  float get() override { return e_->GetPaired(); }
  void setDefault() override { e_->SetPaired(false);  }
      strcpy(x, "paired");
      PairedVariable var1(e);
      op->run(name, &var1);

      struct VolumeVariable : public VariableBase {
  Effect* e_;
  VolumeVariable(Effect* e) : e_(e) {}
  void set(float value) override { e_->SetVolume(value); }
  float get() override { return e_->GetVolume(); }
  void setDefault() override { e_->SetVolume(100);  }
      strcpy(x, "volume");
      VolumeVariable var2(e);
      op->run(name, &var2);

      struct RepeatVariable : public VariableBase {
  Effect* e_;
  RepeatVariable(Effect* e) : e_(e) {}
  void set(float value) override { e_->SetRepeat(value > 0.5); }
  float get() override { return e_->GetRepeat(); }
  void setDefault() override { e_->SetRepeat(false);  }
      strcpy(x, "repeat");
      RepeatVariable var3(e);
      op->run(name, &var3);

When I realized this is wrong for hum, for fun I tried setting config.ini to just repeat the same clash just to test my added code bits.
Then when that didn’t work, I called it a night.

I meant “paired”.

OMG that was easy LOL
Hum repeating easy peasy just doing ProffieOS.SFX.hum.paired=1


1 Like