VividShaper by VividSynths (Released)

VividSynths

Thanks a lot for all these comments. Very useful indeed! 😀

McD

I did not know that AUv3 parameters could accept 14-bit “CC” input… it probably accepts 14-bit Pitch Bends which is the standard. And Surface Builder probably sends 14-bit pitch bends and 7-bit CC’s. CC’s can jump all over the 0-127 space. In the process to push MIDI into a more controllable world we have seen Pitch bend gets applied on a per channel basis to make Midi Polyphonic Expression (MPE) work.

FYI: I just forwarded some Pitch Bends into VividShaper and it isn’t implemented.

hes

@McD said:
I did not know that AUv3 parameters could accept 14-bit “CC” input… it probably accepts 14-bit Pitch Bends which is the standard. And Surface Builder probably sends 14-bit pitch bends and 7-bit CC’s. CC’s can jump all over the 0-127 space. In the process to push MIDI into a more controllable world we have seen Pitch bend gets applied on a per channel basis to make Midi Polyphonic Expression (MPE) work.

FYI: I just forwarded some Pitch Bends into VividShaper and it isn’t implemented.

Not sure what you're trying to do, but sounds like you're trying to get finer control of VividShaper from outside by sending 14 bit CC's. Even if not technically supported, pretty sure you could rig up something using, e.g., the XY pad in Mozaic to send 14 bits of info. Essentially, you'd be using the two axes of the xy control to give finer control over a single modulation target in VividShaper. So you'd be sending two CC messages, each a different cc#, and one of them you would multiply by 128 within Vividshaper and add to the other, before (possibly transforming and) applying to a VividShaper modulation target. The code in Mozaic might look like this (I assume you could do something similar with xy pads in Surface Builder, which is probably better b/c I expect it lets you put as many xy pads as you want on a page):

@OnXYChange
   y = GetYValue
   x = GetXValue

   SendMIDICC <channel>, <y-cc>, y      // multiply this one by 128 in VividShaper
   SendMIDICC <channel>, <x-cc>, x       // add this to product of previous line in VividShaper
                                      // to get your single 14-bit resolution modifier
@End

Yes, it's a hack.

espiegel123

@McD said:
I did not know that AUv3 parameters could accept 14-bit “CC” input… it probably accepts 14-bit Pitch Bends which is the standard. And Surface Builder probably sends 14-bit pitch bends and 7-bit CC’s. CC’s can jump all over the 0-127 space. In the process to push MIDI into a more controllable world we have seen Pitch bend gets applied on a per channel basis to make Midi Polyphonic Expression (MPE) work.

FYI: I just forwarded some Pitch Bends into VividShaper and it isn’t implemented.

McD: AUv3 parameters aren’t midi. Some hosts will translate midi events to AUv3 parameter changes. The AU doesn’t do it. The host does.

wim

4Pockets Surface Builder has support for sending 14-bit CCs.

hes

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

Ah, I wasn't clear about what @McD was doing (and remain so).

Still, do synths generally have support for accepting 14-bit cc's? If not (which is most likely) then you could use something like above hack on your external controller to disassemble the 14-bit value into 2 separate CC's (divide by 128 for most significant 127, and 'modulo 128' for less significant 127) before sending two separate cc's to the synth. Because you have programmatic control over things in VividShaper you could then reassemble into the single 14-bit value, but I assume not in most other synths.

wim

@hes said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

Ah, I wasn't clear about what @McD was doing (and remain so).

Still, do synths generally have support for accepting 14-bit cc's? If not, then you could use something like above hack on your external controller to disassemble the 14-bit value into 2 separate CC's (divide by 128 for most significant 127, and 'modulo 128' for less significant 127) before sending two separate cc's to the synth. Because you have programmatic control over things in VividShaper you could then reassemble into the single 14-bit value, but I assume not in most other synths.

Most synths and hosts don't support 14-bit cc's.

wim

Slightly OT, but here's a quick demo script for sending 14-bit CC's from Mozaic knobs or faders

@Description
Demo - Send 14-Bit CC from knobs
@End

@OnLoad
  // 14-bit CC's are a combination of any of the 1st 32 CC numbers for the msb
  // and a CC 32 higher for the lsb
  _msbCC = [1,2,3,4,5,6,7,8,9,10]
  _lsbCC = [33,34,35,36,37,38,39,40,41,42]
  _channel = [0,0,0,0,0,0,0,0,0]
  
  if Unassigned init
    init = YES
    for knob = 0 to 9
      SetKnobValue knob, 0
      LabelKnob knob, 0
    endfor
    ShowLayout 3
  endif
@End

@OnKnobChange
  knob = LastKnob
  value = GetKnobValue knob
  val_14Bit = Round (TranslateScale value,0,127,0,16383)
  
  msb = Div val_14Bit, 128
  lsb = val_14Bit % 128
  
  SendMIDICC _channel[knob], _msbCC[knob], msb
  SendMIDICC _channel[knob], _lsbCC[knob], lsb
  Log {Knob: }, knob, { | MSB: }, msb, { | LSB: }, lsb, { | Value: }, val_14bit, { | Knob Value: }, value
  LabelKnob knob, val_14Bit
@End

hes

@wim said:
Slightly OT, but here's a quick demo script for sending 14-bit CC's from Mozaic knobs

I don't understand why anybody would want to do it that way. It sends 14-bit values, but with only 7-bit resolution given that you're translating a single knob of 0 to 127 to 14 bits, i.e, still only 128 discrete 14-bit values are possible. You can, on the other hand, send 14-bit values with actual 14-bit resolution if you use xy pad (or two knobs in combination, or one knob if you have separate coarse[msb] and fine[lsb] modes -- maybe with shift key activation) as your control. Am I misunderstanding something?

wim

@hes said:

@wim said:
Slightly OT, but here's a quick demo script for sending 14-bit CC's from Mozaic knobs

I don't understand why anybody would want to do it that way. It sends 14-bit values, but with only 7-bit resolution if you're using a single knob, i.e, only 128 discrete values are possible. You can, on the other hand, send 14-bit values with actual 14-bit resolution if you use xy pad as your control. Am I misunderstanding something?

EDIT: Ah, okay, now I see, you're using two knobs at same time. Or maybe not, do coarse adjustments with one, then turn to the second knob for fine tuning. That works, but seems better to just require one finger on the xy pad to do the same thing. Limited by number of xy pads in Mozaic, but not in Surface Builder.

No. I'm not using two knobs at the same time. I'm converting the decimal part of a single knob value into the 2nd 7-bit value. Mozaic knobs have a resolution of 0.0001. They have more than just integer values.

There could be some loss of finger motion range vs. the XY pad but the benefit is being able to send more 14-bit values than just the XY pad.

Gavinski

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

wim

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Gavinski

@wim said:

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Reinstall time maybe, cheers!

espiegel123

Hi a. > @Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

reboot and try again. post screenshots of the session and midi matrix if it happens again.

McD

This is what I have been laboring over. Sending CC’s that change the Envelope and Harmonic values while displaying those values in a TEXT output. It’s working. Change CC values to match your controller. The Last_Harmonic has great change on this Sine Wave input adding extra highs and complexity.

-- Patch: CC control Envelope and Harmonics
wave[1] = VSSin(1, 0)
local attack = ncc[20]*5
local decay =  ncc[21]*5
local sustain = ncc[22]*5
local release = ncc[23]*5
local volume_initial = ncc[24]
local wavenumber = 1
local first_harmonic = cc[25] + 1
local last_harmonic = cc[26] % 10
local time = gatetimeon + gatetimeoff

if attack == 0 then
  attack = 0.1
  decay =  0.2
  sustain = 0.3
  release = 0.4
  volume_initial = 1.0
  first_harmonic  = 1
  last_harmonic = 4
end

text = string.format("%s%.1f %s%.1f %s%.1f %s%.1f %s%.1f %d%d","A:",attack,"D:",decay,"S:",sustain,"R:",release,"V:", volume_initial,first_harmonic,last_harmonic,time)

-- Try different values of numHarmonics to add or reduce overtone complexity


for i = first_harmonic, last_harmonic do
    local frequency = i
    local harmonic = VSSin(frequency, 0)
    local weight = (gatetimeon+gatetimeoff)/(i)
    wave[wavenumber] = VSAdd(wave[wavenumber], VSMul(harmonic, weight))
end

wave[wavenumber] = VSNorm(wave[wavenumber],0.8,0.8)
vol[wavenumber] = velocity*VSADSRE(attack, decay, sustain, release, volume_initial, gatetimeon, gatetimeoff)
updatefreq = 512
gvol = 0.5

wim

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Reinstall time maybe, cheers!

Is it possible that you were trying to connect the Standalone app? When I load the standalone app I only see the "Surface Builder In" destination in AUM.

You should be running Surface Builder as an AUv3 in AUM. If for some reason you do want to use the standalone app, you'll need to set the output port mappings to AUM, then route from AUM Destination to whatever you want to control.

Pxlhg

@McD said:
This is what I have been laboring over. Sending CC’s that change the Envelope and Harmonic values while displaying those values in a TEXT output. It’s working. Change CC values to match your controller. The Last_Harmonic has great change on this Sine Wave input adding extra highs and complexity.

Sweet! I tested it with this (image) and it works like a charm, the automated values needs to be polished to be more correct for it's purpose respectively, but as a start - great!! Big thanks McD!

Pxlhg

I found this while looking for something completely different, a Lua Script - Plugin/instrument maker for desktop. Maybe can be of some interest for @VividSynths , @McD and others getting into Lua as a music making coding environment. I mean for getting ideas, seeing solutions, formulas whatnot

OSAR :: Protoplug

Gavinski

@wim said:

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Reinstall time maybe, cheers!

Is it possible that you were trying to connect the Standalone app? When I load the standalone app I only see the "Surface Builder In" destination in AUM.

You should be running Surface Builder as an AUv3 in AUM. If for some reason you do want to use the standalone app, you'll need to set the output port mappings to AUM, then route from AUM Destination to whatever you want to control.

Oh god no, I never use auv3s standalone if I can help it!

wim

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Reinstall time maybe, cheers!

Is it possible that you were trying to connect the Standalone app? When I load the standalone app I only see the "Surface Builder In" destination in AUM.

You should be running Surface Builder as an AUv3 in AUM. If for some reason you do want to use the standalone app, you'll need to set the output port mappings to AUM, then route from AUM Destination to whatever you want to control.

Oh god no, I never use auv3s standalone if I can help it!

Maybe try running it standalone once and then try the AUv3 again. Some apps need that in order to fully complete their installations.

Bruques

@VividSynths said:
That would be really cool, to allow creating weird patches and then also allowing a unique way of randomising some parameters for each patch.

I think the easiest way would actually be something like this:

    -- Patch: mypatch
    seed = 1231
    
    math.randomseed(seed)
    attack = math.random()*5 -- Generate number between 0 to 5
    decay = math.random()*3 -- Generate number between 0 to 3
    sustain = math.random() -- Generate number between 0 to 1
    release = math.random()*3 -- Generate number between 0 to 3
    waveform = math.random(1,3) -- Generate random number 1, 2, or 3
    
    
    if waveform == 1 then 
      wave[1] = VSTriangle(1,0)
    else if waveform == 2 then
      wave[1] = VSSaw(1,0)
    else if waveform == 3 then
      wave[1] = VSSquare(1,0,0.5)
    endif
    text = seed

Etc..

Every time you run this code, you will get the same random numbers, but if you change the seed to something else you will get a different set of random numbers. The problem is that you have to manually change the seed number every time you want a new patch. It is not possible today to solve this, but I could add a new variable "parsecounter" that increment with one every time you press parse (starting with 1). In that case, you could just do this: seed = parsecounter. The current seed is then printed with "text = seed", so you know which seed that created an interesting patch.

An alternative approach is to connect it to CC-messages:

seed = cc[20]+cc[21]*127

This way, you can generate new patches by changing the CC 20 and 21.

Why would you not seed it using os.time() or os.clock()? These values will constantly increment, albeit rounded to seconds, so wouldn't be random per (pseudo buffer) call

Bruques

@Bruques said:

@VividSynths said:
That would be really cool, to allow creating weird patches and then also allowing a unique way of randomising some parameters for each patch.

I think the easiest way would actually be something like this:

    -- Patch: mypatch
    seed = 1231
    
    math.randomseed(seed)
    attack = math.random()*5 -- Generate number between 0 to 5
    decay = math.random()*3 -- Generate number between 0 to 3
    sustain = math.random() -- Generate number between 0 to 1
    release = math.random()*3 -- Generate number between 0 to 3
    waveform = math.random(1,3) -- Generate random number 1, 2, or 3
    
    
    if waveform == 1 then 
      wave[1] = VSTriangle(1,0)
    else if waveform == 2 then
      wave[1] = VSSaw(1,0)
    else if waveform == 3 then
      wave[1] = VSSquare(1,0,0.5)
    endif
    text = seed

Etc..

Every time you run this code, you will get the same random numbers, but if you change the seed to something else you will get a different set of random numbers. The problem is that you have to manually change the seed number every time you want a new patch. It is not possible today to solve this, but I could add a new variable "parsecounter" that increment with one every time you press parse (starting with 1). In that case, you could just do this: seed = parsecounter. The current seed is then printed with "text = seed", so you know which seed that created an interesting patch.

An alternative approach is to connect it to CC-messages:

seed = cc[20]+cc[21]*127

This way, you can generate new patches by changing the CC 20 and 21.

Why would you not seed it using os.time() or os.clock()? These values will constantly increment, albeit rounded to seconds, so wouldn't be random per (pseudo buffer) call

@VividSynths if you were to include LuaSocket in the build then users could have access to socket.gettime()*1000
That would mean every call to that would generate a different seed and thus changing random results

https://stackoverflow.com/questions/463101/lua-current-time-in-milliseconds

McD

Good idea for random seeding using system time.

I hacked out a test on an iPhone… try that sometime!

-- Patchs: Random Time Seeding
vol[1]=gate
time1 = os.time() % 99
time2 = os.time() % 99
time3 = os.time() % 9
-- Patch: Random Time Seeding
vol[1]=gate
time1 = os.time() % 99
time2 = os.time() % 99
time3 = os.time() % 9
time = time1*time2*time3
text = string.format("%.4f", time)
wave[1] = VSNoise(time)
vol[1]=gate
notenum = (notein % 12) + 1
note[1] = notein
updatefrequncy = 2048
gvol = 0.5  = time1*time2*time3
text = string.format("%.4f", time)
wave[1] = VSNoise(time)
vol[1]=gate
notenum = (notein % 12) + 1
note[1] = notein
updatefrequncy = 2048
gvol = 0.5 

Bruques

@Bruques said:

@Bruques said:

@VividSynths said:
That would be really cool, to allow creating weird patches and then also allowing a unique way of randomising some parameters for each patch.

I think the easiest way would actually be something like this:

    -- Patch: mypatch
    seed = 1231
    
    math.randomseed(seed)
    attack = math.random()*5 -- Generate number between 0 to 5
    decay = math.random()*3 -- Generate number between 0 to 3
    sustain = math.random() -- Generate number between 0 to 1
    release = math.random()*3 -- Generate number between 0 to 3
    waveform = math.random(1,3) -- Generate random number 1, 2, or 3
    
    
    if waveform == 1 then 
      wave[1] = VSTriangle(1,0)
    else if waveform == 2 then
      wave[1] = VSSaw(1,0)
    else if waveform == 3 then
      wave[1] = VSSquare(1,0,0.5)
    endif
    text = seed

Etc..

Every time you run this code, you will get the same random numbers, but if you change the seed to something else you will get a different set of random numbers. The problem is that you have to manually change the seed number every time you want a new patch. It is not possible today to solve this, but I could add a new variable "parsecounter" that increment with one every time you press parse (starting with 1). In that case, you could just do this: seed = parsecounter. The current seed is then printed with "text = seed", so you know which seed that created an interesting patch.

An alternative approach is to connect it to CC-messages:

seed = cc[20]+cc[21]*127

This way, you can generate new patches by changing the CC 20 and 21.

Why would you not seed it using os.time() or os.clock()? These values will constantly increment, albeit rounded to seconds, so wouldn't be random per (pseudo buffer) call

@VividSynths if you were to include LuaSocket in the build then users could have access to socket.gettime()*1000
That would mean every call to that would generate a different seed and thus changing random results

https://stackoverflow.com/questions/463101/lua-current-time-in-milliseconds

Couple other possibilities (I haven't tried for myself as I don't actually have vividsynth yet) -
If wave[x] is VSNoise, after that wouldn't reading wave[x]'s amplitude value report back ostensibly random values that could be used to seed other random values? IE noise is not periodic, so every single call to check on wave[x] should return different values each and every time right? Thus a VSNoise can itself be a seed source, or no?

also, you have tick already right? so once per call you have a different counter to use as a seed.

Or, given @VividSynths that the synth itself is work at the sample level and constantly dealing in milliseconds, just add an elapsed milliseconds getter to the vividAPI? getVividTime()? that said,, your counter solution just works anyway. every time it's called its incremented so sorted.

Typing out loud

Gavinski

@wim said:

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:

@Gavinski said:

@wim said:
4Pockets Surface Builder has support for sending 14-bit CCs.

I tried to use surface builder to send pitch bend via a rotary knob to something yesterday in aum, but noticed surface builder only appeared as a destination, not a source. Thoughts?

I can't reproduce that here and haven't heard it reported elsewhere.

Reinstall time maybe, cheers!

Is it possible that you were trying to connect the Standalone app? When I load the standalone app I only see the "Surface Builder In" destination in AUM.

You should be running Surface Builder as an AUv3 in AUM. If for some reason you do want to use the standalone app, you'll need to set the output port mappings to AUM, then route from AUM Destination to whatever you want to control.

Oh god no, I never use auv3s standalone if I can help it!

Maybe try running it standalone once and then try the AUv3 again. Some apps need that in order to fully complete their installations.

Did that, will try a reboot tho I think that was one of the things I already tried, let's see!

Bruques

@McD said:
Good idea for random seeding using system time.

I hacked out a test on an iPhone… try that sometime!

-- Patchs: Random Time Seeding
vol[1]=gate
time1 = os.time() % 99
time2 = os.time() % 99
time3 = os.time() % 9
-- Patch: Random Time Seeding
vol[1]=gate
time1 = os.time() % 99
time2 = os.time() % 99
time3 = os.time() % 9
time = time1*time2*time3
text = string.format("%.4f", time)
wave[1] = VSNoise(time)
vol[1]=gate
notenum = (notein % 12) + 1
note[1] = notein
updatefrequncy = 2048
gvol = 0.5  = time1*time2*time3
text = string.format("%.4f", time)
wave[1] = VSNoise(time)
vol[1]=gate
notenum = (notein % 12) + 1
note[1] = notein
updatefrequncy = 2048
gvol = 0.5

Ok great!
(i will get it myself by next month)

McD

@Bruques said:
Ok great!
(i will get it myself by next month)

I hope you can… It will be fun to have a group discovering together and sharing results.

There are a million synths but only a couple that expose sound design in this programmatic way.

The neural net feature is the best innovation for me in this app. I love synths where the waves morph with time and it’s a great tool to define those subtle changes in sound and keep it fresh. All the work has been done building the grid of possible waves and you just need to provide x and y numbers between -1 and 1 to get a wave. Provide a series of xy pairs with small distance from the previous and the waves change right before your eyes in the graphical viewer and you can hear it morph.

There’s simple math provided that turns circles around in the grid serving up x,y pairs but so many ways yet to explore.

Obviously, a joy stick interface (or touch XY Pad) Preset would be useful to navigate the grid for various sounds.

With 8 oscillators there will be complex combinations to overlay.

hes

@wim said:

No. I'm not using two knobs at the same time. I'm converting the decimal part of a single knob value into the 2nd 7-bit value. Mozaic knobs have a resolution of 0.0001. They have more than just integer values.

Ahhh, thanks! I can't recall ever using the decimal part of Mozaic knob values and forgot that they weren't integers.

VividSynths

@McD said:
I did not know that AUv3 parameters could accept 14-bit “CC” input… it probably accepts 14-bit Pitch Bends which is the standard. And Surface Builder probably sends 14-bit pitch bends and 7-bit CC’s. CC’s can jump all over the 0-127 space. In the process to push MIDI into a more controllable world we have seen Pitch bend gets applied on a per channel basis to make Midi Polyphonic Expression (MPE) work.

FYI: I just forwarded some Pitch Bends into VividShaper and it isn’t implemented.

Sorry, I missed this comment. Yes, I definitely need to implement this. While notein tells the current note, pitchbend will tell the current bending (as a floating point value). Then, I'm considering to let the default note[x] array (telling the note for each oscillator) be notein+pitchbend by default. This will actually allow us to use pitchbend for something else, e.g. controlling filters.

I just released version 1.3 of VividShaper for both iOS and macOS. It comes with a new delay effect:

I am currently working on version 1.4, which will focus on MIDI, but I will most likely make an update with pitch bend first.

Version 1.4 will include a new function called VSPlay(), where you can play notes as a string of characters when using VividShaper as a MIDI effect plugin. it will be very similar to the PLAY() function in Commodore 128 BASIC:

https://www.commodore.ca/manuals/128_system_guide/sect-07b.htm#7.3.2.3

It will work something like this:

VSPlay("O3QCEGEGED",start,midichannel)

where start is the start position of the first note counted as number of beats. This means you will be able to use VividShaper as a MIDI-sequencer. Well, actually, you can already do that with the MIDI functions it already has, but these are a bit more difficult to master.

garden

I saw this update show up and was pleasantly surprised. I hope to carve out some time to get back to tinkering with it again.