VOSIM Possible in Axolotl?

#11

There's a 'pitch shifter' example in the Axoloti examples using a delay modulated with a phasor object. It stutters but I wonder if two delay-reads were set up 180 out of phase with crossfading to mask the wrap-around you might get a passable pitch shifter.
You're not going to get any kind of autotune without some method of reading the current pitch of the input though, otherwise it wouldn't know how much to pitch shift by to 'retune' the input.

#12

I was thinking of interleaving two granular players, too.

I wasn't thinking so much of a pitch-shifter, as something akin to granular pitch-freezer that would force the input audio (would have to be monophonic, probably) to the pitch of the carrier wave, possibly by looping sections of a buffer in sync with a a carrier. Something like a cheap, realtime version of the NI Kontakt Time Machine mode.

There's a (now discontinued) Euro module called the Pitch-Shaper
http://www.gotharman.dk/Pitchshaper.htm
which does something like this, I think, so I'm sure it's possible.

a|x

#13

I was just going by your use of the term auto-tune (which is basically a pitch shifter being intelligently controlled in response to pitch detection).

I sort of see where you're going with it, I'm not sure whether it would be possible in real-time though. It might be possible to sample the input into a table and then play that back granularly at a controllable pitch.

#14

Sorry, yes, wrong terminology there.

This is what I have in mind:

  • Granular playback of looped sections of input waveform
  • At the start of each grain, a section of the input audio is grabbed and looped for the duration of the grain
  • The length of the loop determines the perceived pitch of the resulting output
  • The grain length would have to be long enough so that several cycles of the loop could be played
  • There would be two grains playing at any given time, and the two grains would overlap, and be shaped to create a smooth crossfade between each looped segment

Does this sound feasible? It's essentially realtime wavetable synthesis.

a|x

#15

I should probably start another thread about this.
Actually, I should probably try and get VOSIM working, first...

a|x

#16

Check this out: formant osc.axs (7.0 KB)

Basically there's a phasor oscillator that splits into two routes: the first is a sine wavefolder that allows to obtain sine pulses in a variable amount (but they are always phase synced with the phasor since they're generated this way!).
The second route is the "window" route, which allows to give a specific shape to the waveform.

In the end the window and the sine pulse train are multiplied and outputted.

Also, since the phasor object has audio rate fm input i added a sine oscillator to provide mixed synthesis techniques. The resulting object is somewhat heavy, with 8% dsp load. Eliminating the fm path would free 1%. There's some heavy aliasing at high pitches (which however would not be harmonically very interesting.

Sputnki contributions
#17

Looking forward to giving this a try!

a|x

#18

Anyone know if this is possible with Axolotl?
http://bagger288.com/goldenmaster/vosim-synthesis-for-the-masses/25
It looks very simple, but doesn't seem to be possible with Factory objects (requires s-rate VCA).

It is "almost" possible to create the VOSIM algorithm. I have a semi-working patch, but before posting it I would like to know two things:
1) is there is a way of getting a saw oscillator which is a decaying one, not a rising one.
I can create one by setting the cheap saw oscillator, then set a constant to 64 and subtract from this the output of the saw, but the constant is a green output and when connecting it to the math/- object the green cable is a dashed line. It seems to work, but I do not know if this is the correct way of doing this.

2) How does the phase red input of the osc/sine oscillator work? I mean what value triggers the phase?
Edit: I realised that I want to use a sync'ed sine oscillator but the toneburst/sinesync object does not compiles on 1.0.8.
Thanks

#19

Did you try inverting the output of the oscillator? I am pretty sure that will give a decaying saw, as you describe it. There is an red(audio rate) inverter.

#20

Ah, excellent, thanks!

#21

Here is the error I get when trying to compile a patch containing the @toneburst sinesyc
oscillator in 1.0.8-28-g5b96816-dirty
Any ideas?
Thanks


Generate code complete
Start creating directory on sdcard : /VOSIM
creating dir: /VOSIM
Done creating directory
Changing working directory on sdcard : /VOSIM
Axoloti says: file error: FR_NOT_ENABLED, filename:"/VOSIM"
Change working directory: /VOSIM
Done changing working directory
Start compiling patch
Axoloti says: file error: FR_NOT_ENABLED, filename:"/VOSIM"
Compiling patch... with /home/gabriel/axoloti/firmware
BDIR = /home/gabriel/axoloti/build
FIRMWARE = .
RM
rm -f /home/gabriel/axoloti/build/xpatch.o /home/gabriel/axoloti/build/xpatch.elf /home/gabriel/axoloti/build/xpatch.bin /home/gabriel/axoloti/build/xpatch.d /home/gabriel/axoloti/build/xpatch.map /home/gabriel/axoloti/build/xpatch.lst
APP
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -H -I/home/gabriel/axoloti/CMSIS/Include -I/home/gabriel/axoloti/chibios/os/ports/common/ARMCMx/CMSIS/include -I/home/gabriel/axoloti/chibios/os/ports/common/ARMCMx -I/home/gabriel/axoloti/chibios/os/ports/GCC/ARMCMx -I/home/gabriel/axoloti/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/home/gabriel/axoloti/chibios/os/kernel/include -I/home/gabriel/axoloti/chibios/os/hal/include -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32F4xx -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/GPIOv2 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/I2Cv1 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/OTGv1 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/RTCv2 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/SPIv1 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/TIMv1 -I/home/gabriel/axoloti/chibios/os/hal/platforms/STM32/USARTv1 -I/home/gabriel/axoloti/chibios/boards/ST_STM32F4_DISCOVERY -I/home/gabriel/axoloti/chibios/ext/fatfs/src -I. -I/home/gabriel/axoloti/chibios -Winvalid-pch -MD -MP --include /home/gabriel/axoloti/build/xpatch.h -c /home/gabriel/axoloti/build/xpatch.cpp -o /home/gabriel/axoloti/build/xpatch.o
! /home/gabriel/axoloti/build/xpatch.h.gch
/home/gabriel/axoloti/build/xpatch.cpp:214:3: error: expected unqualified-id before 'public'
public: void Init(rootc * _parent) {
^
/home/gabriel/axoloti/build/xpatch.cpp: In member function 'void rootc::Init()':
/home/gabriel/axoloti/build/xpatch.cpp:743:26: error: 'class rootc::instancesinesync__1' has no member named 'Init'
instancesinesync__1_i.Init(this );
^
Makefile.patch:58: recipe for target '/home/gabriel/axoloti/build/xpatch.bin' failed
make: *** [/home/gabriel/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /home/gabriel/axoloti/patches/VOSIM.axp )

#22

^ There's a dangling "uint32_t" in the < code.declaration > section. If you remove that, it compiles.

BTW, I wonder, will my local change to tb/osc/sinesync.axo propagate to the git repository on a library sync, or am I protected from that?

Edit: Ooops, the change did propagate - sorry, Toneburst :blush:

#23

Sorry guys, that object is something I started, and never got around to finishing. It got uploaded to the Community Library by mistake.

If anyone wants to finish it, that would be cool. I was just intending to add an S-Rate boolean input to reset the phase of the oscillator 0.

a|x

#24

I added sync functionality to it. Not a with boolean input tough, as you had already added a fractional input, so I took it that fractional was the actual intention, and more in line with the other oscillators (can still be synced with a Boolean, but needs a conv/nointerp before the sync input). Hope that's ok. There's no bandlimiting - I suppose Johannes' snappy blep implementation could be added. It does give vocal like qualities with a lower master than slave frequency.

My previous unintentional update to toneburst/osc/sincesync/ did propagate to the git repository. This one didn't though, so I edited it at the git site.

@thetechnobear : Did permissions get changed at the git repo after my previous excursion into forbidden territory?

#25

no... in practice all contributors could (but should not) update anyones objects/patches etc
BUT entering a contributor prefix tells the UI not to commit changes outside your area.

(github does not have any fine level permission, well not at least on public/non org repos)

I repeat though, you should not update others objects/patches.

the reason is very simple...

its possible you could create a conflict, this would put others users local repos into conflict, which we provide no tools to resolve, and we cannot expect users to have git experience or tools to resolve. (unlike in a true dev environment)

so this could be a support nightmare (when we get to a position where all users are using the libraries, not just in testing)
the only resolution for them would be to init() the community library again, but that could mean they loose changes.

SOOO... I dont want to go down this route.

Now... I do know, that if you are careful this won't happen... (and i do it occasionally) but we really cant take this risk, as I cant know that any particular user knows what they are doing. so in practice i take a very dim view of it, and they do cause issue then I will get their access revoked :wink:

(note: if I do it e.g. file renaming/deleting/editing - I do it in conjunction with the contributor so that I know they are not updating, hence I know there will not be a chance of conflict)

#26

I basically agree, tb. In this case toneburst requested collaboration on an object, so I did that. But yes, It would be best if changes to other's objects weren't possible, except by invitation,

Users will want to collaborate at library object level; I have two such things going as we speak, both being requests. For "safe" collaboration, perhaps we should stick to the github-site tools when we need to change each others files?

(as for the update itself: it worked fine yesterday, but today my local updated (toneburst's) file did not get pushed to the git repo, thus I though permission had changed)

#27

In 1.0.9 toneburst sinesync oscillator can compile, but appears in the list of objects as:
toneburst/osc/toneburst/osc/sinesync
Is that right?
Also while it compiles, I am not sure it is working as I was expecting. The VOSIM patch still has a residual low frequency fluctuation which I think has to do with some issue with the sync of the sine oscillator.

VOSIM.png776x331 20.7 KB

and here is the patch (uploaded again)
VOSIM.axp (3.2 KB)

#28

yup, I know, and understand its going to happen sometimes... just need to explain the issues, so we are 'careful' :smile:

of course, git is pretty good at merging things, my concern is not only conflicts but automatic merges which create invalid object/patch files, that then have to be manually edited, as only a few have the skills to do this... so for some a 'damaged' patch file is unreadable.

of course we do have the power to reverse changes etc, so all is not lost... its just a matter of trying to keep admin/moderating work to a minimum

#29

I had to edit .axh files a lot lately. Every time I tried to use an embedded sub-patch in 1.0.8, the file couldn't be re-opened, so I had to remove the object from the XML using a text-editor.

It's good that you can do this, though. The decision to base all file-formats on human-readable XML was a good one, I think.

a|x

#30

I was getting this a LOT when working with custom objects in 1.0.8.

Sometimes parts of the path would be duplicated in the title bar, so the object would end up stupidly wide.

The only way I found to fix it was to open the object in a text editor and remove the extraneous ID text that way.

As I think has been noted before, 1.0.8 was a bit broken, when it came to editing custom objects. Hopefully 1.0.9 will have fixed some of the bugs.

a|x