VOSIM Possible in Axolotl?

#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

#31

yeah, I fixed this all in 1.0.9 ... (let me know if there are any remaining issues)

#32

Thanks for doing this. As you say, I was perfectly happy for this to be fixed.

a|x

#33

Your patch doesn't seem to be available anymore, unfortunately. Could you re-upload it, I'd like to give it a try.

Cheers,

a|x

#34

Not sure what happened there. Can you try again?

#35

I made my own VOSIM-version. Thereto I created a new object (jho/phasor fast sync.axo) for the signal-rate reset, with a less strict sync behaviour than sinesync.axo. You'll find the VOSIM-patch as help-file (phasor fast sync.axh).

#36

Ah, very nice, thanks.

#37

Will try that, too!
It's interesting to see how many different ways there are to do the same thing.

a|x