Quantcast
Channel: Axoloti Community - Latest posts
Viewing all 24308 articles
Browse latest View live

Next-gen and mini Axoloti hardware discussion

$
0
0

Don't want to stir up any heated debate again but I do have some insights to share if anyone are serious about getting into audio professional/commercial business.

Any core boards should be as close to your own business as possible (design files, bill of materials etc). You should need to be able to switch to any PCB manufacturer at any moment for any reason.
If you have bought loads of periheral parts to have in stock (i e header cable with connectors/jacks as suggested to be of use in the connectivity of these boards in this thread), you'd easily be in deep trouble if you are only in second position in sourcing the core boards that you are planning to connect with your peripheral parts. What do you do if you have customers waiting to buying your products but your original core board supplier has withdrawn their ability to deliver for any reason and you don't have any design files etc?

Secondly, who would be responsible to handle any warranty of your products if there are a core board that you have pretty much no control over (any design alteration may affect your product capabilities drastically)?

Any type of connector/jack with header cable is quite an manual labour in production. Which unfortunately usually means expensive to buy unless you buy a huge amount from a supplier. There are quite some options out there regarding connectors/jacks to choose from. And what lengths should the header cables be provided in?

Big professional brands may/often use such solution between core, ui and i/o boards. Some of the reasons are ease of manufacturing, further development and/or alteration in any of those boards area. As well as ease of fault test/repair.

I haven't seen it myself regarding the connector/jacks themselves having a header cable at their end. But they probably exist somewhere in some product out there. Point is that the costs probably speaks against it unless it is a niche product. Which probably is why you/me/we don't see it more often in commercial products.

In production/assembly you often see either an i/o board solution (header - header) with specific configuration of connectors/jacks OR a core board with specific configuration of connectors/jacks.


Axoloti release 2.0.0

$
0
0

i think the key here, is remembering about startup patches, and also ones loaded by patch banks
(as ones you loading in via the editor will be recompiled anyway :wink: )

e.g. i noticed i was getting the following warning
unidentified header : 0x726F7841

I believe this was caused by an old startup patch on the board.

How to read a table two subpatch levels deep

$
0
0

you use attributes (see table/read as an example) to get the names,
then you need to be very careful of things likes scaling (again see table/read and write for examples)

but its very likely you do NOT want to do this... since if your not careful you'll just re-create the same issue in your own object :wink:
what you want to do is a singleton pattern (or a global static if you wanna be a bit hacky) , this will then be in scope to all objects, regardless of where they are in the patch.

(note to self: I need to have a look at this in 2.0, see if the new memory/patch layout changes this at all!)

Axoloti release 2.0.0

$
0
0

Ah yeah, I see. I don't have any start up patch, as far as I remember, so that should not be an issue here.

Can I somehow reset a start up patch, so I can make sure there isn't any start up patch at all?

Axoloti release 2.0.0

$
0
0

Yeah there’s an erase startup patch option on menu. ( new in 2.0?)

Axoloti release 2.0.0

$
0
0

Yeah I think it must be a new feature in 2.0. I just looked for it in 1.0.12 and I don't see it there.

So I should probably try the new 2.0 out on one of my boards anyway :slight_smile:

How to read a table two subpatch levels deep

$
0
0

Thanks @thetechnobear

Are there any beginner resources for this?

I've never even heard of singleton patterns. I don't mind being hacky but I am a real beginner in c++. I don't know where to start.

If I could access the tables in an object and do all the computations within the object, I think I could save a bunch of ram. But when a table is read within an object, within a subpatch, is it still two subpatch levels down? Because if it is essentially just one level down, then it could work. Right?

How to read a table two subpatch levels deep

$
0
0

Yes one reason is because you would have a lot less inlets and outlets, which uses sram.


How to read a table two subpatch levels deep

$
0
0

As a quick aside, in case it's useful -

regarding poly patches: for my poly midi Looper I have a table in the parent patch and then use polyindex inside the poly subpatch to tell it where to right into the table. Like, if polyindex=0 write to offset 0, if polyindex=1 write to offset 100, or whatever. Haven't touched mpe though...

How big are the tables? If they're small I wouldn't worry about them being multiplied. Thinking about it, isn't it more or less the same? Instead of one big table in the parent patch you have lots of smaller ones in the subpatches? But then if you needed to save the table it's easier with one big one...

Axoloti release 2.0.0

$
0
0

Installed Axoloti 2.0 on my Macbook Pro (10.14.6)
Renamed it to /Appllications/Axoloti_2

Installed toolchain in /Appllications/gcc-arm-none-eabi-7-2018-q2-update/

Started new Axoloti app, flashed new firmware on my spare Axoloti.
Ran Library/factory/demos/synth/screamer
Success - yes it screams.

Tried to use format object to clean old Raspbian files off the SD card:

Done compiling patch
Generate code complete
compiling /Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'msg_t rootc::instanceformat__1::ThreadX2()':
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:137:28: error: too few arguments to function 'FRESULT f_mkfs(const TCHAR*, BYTE, DWORD, void*, UINT)'
fs_error = f_mkfs(0, 0, 0);
^
In file included from /Applications/Axoloti_2.app/Contents/Java/api/xpatch.h:30:0,
from :0:
/Applications/Axoloti_2.app/Contents/Java/api/fatfs/ff.h:269:9: note: declared here
FRESULT f_mkfs (const TCHAR* path, BYTE opt, DWORD au, void* work, UINT len); /* Create a FAT volume */
^~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:139:3: error: 'sdcard_unmount' was not declared in this scope
sdcard_unmount();
^~~~~~~~~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:139:3: note: suggested alternative: 'f_unmount'
sdcard_unmount();
^~~~~~~~~~~~~~
f_unmount
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:140:3: error: 'sdcard_attemptMountIfUnmounted' was not declared in this scope
sdcard_attemptMountIfUnmounted();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'void rootc::instanceformat__1::dsp(rootc*, int, int, int32_t&, int32_t&, int32_t&)':
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:176:33: error: 'ThreadX' was not declared in this scope
NORMALPRIO, ThreadX, (void *)this);
^~~~~~~
/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.cpp:176:33: note: suggested alternative: 'ThreadX2'
NORMALPRIO, ThreadX, (void *)this);
^~~~~~~
ThreadX2
make: *** [/Users/rfries/Documents/axoloti-2.0.0/build/xpatch.o] Error 1
Compiling patch failed

Axoloti release 2.0.0

$
0
0

I tried win10 gcc-arm-none-eabi-7-2018-q2-update installed getting this error

How to read a table two subpatch levels deep

$
0
0

thanks, I'm not sure how to use polyindex for this. How can I find this poly midi looper? is it in the community patches? I could take a look.

I am not using one big table but a bunch of smaller tables. One for each source (which manages the amounts of mod being sent to all the destinations).

Axoloti release 2.0.0

Axoloti release 2.0.0

Axoloti release 2.0.0

$
0
0

BTW. if I update my board to 2.0 it will still be possible to revert back to 1.0.12, right?


How to read a table two subpatch levels deep

$
0
0

@jaffasplaffa @MattilynMattroe @thetechnobear

Thanks for pointing me in this direction... I had a go at programming my own object and it sort of works... but could use some help making it better. The first version i made, to my surprise, actually works, but still uses up a bit too much ram (i need 44 of them in my voice patch (which means this number is times 4) to link up all the modulation targets. With this version I was able to get 21 of them going. Not bad at all! Huge increase in efficiency.

The first object i made was this:

It collects the appropriate tables. The target attribute corresponds to the offset for that modulation destination, so I'll set that individually for each one. The other attributes are the tables. The mod amounts are processed from unipolar to bipolar, and then they are multiplied with the corresponding values of the modulation sources. Then these are all summed with the initial value and sent to the output.

int te1 = attr_t1.array[_USAT((attrtarget),attr_t1.LENGTHPOW)]<<attr_t1.GAIN;
int te2 = attr_t2.array[_USAT((attrtarget),attr_t2.LENGTHPOW)]<<attr_t2.GAIN;
int tl1 = attr_t3.array[_USAT((attrtarget),attr_t3.LENGTHPOW)]<<attr_t3.GAIN;
int tl2 = attr_t4.array[_USAT((attrtarget),attr_t4.LENGTHPOW)]<<attr_t4.GAIN;
int tx = attr_t5.array[_USAT((attrtarget),attr_t5.LENGTHPOW)]<<attr_t5.GAIN;
int ty = attr_t7.array[_USAT((attrtarget),attr_t6.LENGTHPOW)]<<attr_t6.GAIN;
int tz = attr_t7.array[_USAT((attrtarget),attr_t7.LENGTHPOW)]<<attr_t7.GAIN;

int bpe1 = (te1-(1<<26))<<1;
int bpe2 = (te2-(1<<26))<<1;
int bpl1 = (tl1-(1<<26))<<1;
int bpl2 = (tl2-(1<<26))<<1;
int bpx = (tx-(1<<26))<<1;
int bpy = (ty-(1<<26))<<1;
int bpz = (tz-(1<<26))<<1;

int se1 = attr_ms.array[_USAT((0),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int se2 = attr_ms.array[_USAT((1),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sl1 = attr_ms.array[_USAT((2),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sl2 = attr_ms.array[_USAT((3),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sx = attr_ms.array[_USAT((4),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sy = attr_ms.array[_USAT((5),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sz = attr_ms.array[_USAT((6),attrms.LENGTHPOW)]<<attr_ms.GAIN;

int e1 = ___SMMUL(bpe1<<3,se1<<2);
int e2 = ___SMMUL(bpe2<<3,se2<<2);
int l1 = ___SMMUL(bpl1<<3,sl1<<2);
int l2 = ___SMMUL(bpl2<<3,sl2<<2);
int xt = ___SMMUL(bpx<<3,sx<<2);
int yt = ___SMMUL(bpy<<3,sy<<2);
int zt = ___SMMUL(bpz<<3,sz<<2);

outlet_total = e1 + e2 + l1 + l2 + xt + yt + zt + inlet_initial;

But obviously this is not efficient.

So I've tried to compress everything into a single equation:

outlet_total =
(__SMMUL((((attrt1.array[USAT((attr_target),attr_t1.LENGTHPOW)]<<attr_t1.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((0),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt2.array[USAT((attr_target),attr_t2.LENGTHPOW)]<<attr_t2.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((1),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt3.array[USAT((attr_target),attr_t3.LENGTHPOW)]<<attr_t3.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((2),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt4.array[USAT((attr_target),attr_t4.LENGTHPOW)]<<attr_t4.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((3),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt5.array[USAT((attr_target),attr_t5.LENGTHPOW)]<<attr_t5.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((4),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt7.array[USAT((attr_target),attr_t6.LENGTHPOW)]<<attr_t6.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((5),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt7.array[USAT((attr_target),attr_t7.LENGTHPOW)]<<attr_t7.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((6),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
inlet_initial;

This compiles but for some reason the DSP maxes out...

Any ideas?

The DSP is usually nowhere near maxing out. Is this too much for a single operation or something like that?

Axoloti release 2.0.0

$
0
0

Yes, either use "board->firmware->Flash downgrade to 1.0.12" in Axoloti 2.0, or use "board->firmware->Flash (rescue)" in 1.0.12.

How to read a table two subpatch levels deep

$
0
0

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Axoloti release 2.0.0

$
0
0

About the error "Axoloti - entrypoint not found":
Could you try renaming
C:\Program Files (x86)\Axoloti into C:\Program Files (x86)\Axoloti1,
reboot,
and run the axoloti-win-2.0.0.msi installer again?
Not sure it will solve anything, so far I haven't been able to reproduce this error.

Next-gen and mini Axoloti hardware discussion

$
0
0

Hey everyone. I really appreciate your enthusiasm.

A few of you have contacted me directly with various concerns.

I want to clarify something: everything I've shown in this thread is my work. Johannes is not involved. The device itself will not be called Axoloti. It will ultimately be a separate open source project, derived from the original open source project.

We're approaching a point where it will make sense to move discussion about my project elsewhere, out of respect for the original project and to avoid confusion, etc. This transition will occur when pre-orders go live. Stay tuned for details. I'm not going to post anymore here until then.

I agree with @timeorspace. Let's keep it chill.

Jump on Discord here if you'd like to chat in the meantime: https://discord.gg/xeztjzh

Viewing all 24308 articles
Browse latest View live