Bug in table load?


#1

When I switch between files using the table/load object to select between different samples, the first time after I hit the load button, the table/playpitch object plays the newly selected sample when triggered, but when it gets triggered a second time, it resets to another sample. No matter which sample I choose to load, it always returns to that same sample at the second trigger.. Using the wave/play object, everything works ok and it gets updated to the selected filename.
I also hear a glitching high tone when pressing the load button, is that normal?


#2

Glitching high tone = normal. The BIGGER the tablesize the longer the click/biiiib is. The table has to be reloaded, which results in what you hear.

Could you post a picture of the sample selection method you use = I am not sure I understand how you set it up.


#3

ok, already thought so about the loading-tone. Luckily, it's not too load and my music is full of "glitches" anyways, so nobody would notice :laughing:
So this is the string-selection (still very basic, I first want to make a usable sample library)


#4

Nice you found out :wink:

About the recording/loading issue:

I still think the read/write error could be related to not have anything connected to the position. I still think you should try and use an lfo to record a time period. When you push record like, like you do now, it will only record ONE sample in length, i think, so there is basicly not anything to save or load. For recording a time period you have to connect something to the position inlet, like an lfo. Again I dont have my board right, they are send it for fixing, so I can not test anything. BUT in my wavetabe patch(which I'll finish and post here when I get my boards back) which works for both recording and playback, It ONLY works when I connect something to position inlet.

Try this math for lfo speed:
The table is 262144 samples long.
If you want to make ONE cycle of the lfo 262144 samples long, to scan through the table ONE time......... do this math:

48000/262144 = 0,18310546875 hz

Take a saw lfo and set the speed for 0.1831 hz. Might need to multiply that number up X16 to be able to set the frequency on an lfo. And then use a dial/b to pitch inlet to compensate for the X16. Set the dial/b to MINUS 48. That is equivilant to diving by 16, for perfect compensation.

AND connect the record button to the lfo rst, so you make sure it records from the beginning of the table everytime. AND also connect the saw lfo out(the pulse out of the saw) to stop on table/record..... so it stops after one cycle....... maybe use an inverter like in your own patch to make this work.......... Then you make sure you only record one cycle of the table, 262144 samples, which is 5,461 seconds.

Please try it. If it dont work the wavetable patch will be uploaded in a week or two, for inspiration. THis is just from what I remember from the WT patch. Need to look into it again to be 100%.


#5

I think you are confusing the table-read with the wave play....
The position pin on the "wave/play" is meant to control the starting position of the wave to be played instead of controlling realtime where you're reading out the wave.
The wave/play object only needs a trigger to play it's file, nothing more.

The problem also isn't whether or not something is playing or recording at a certain rate. It IS playing a sample and I can control the rate at which this sample is played and it's also already recording properly...

The problem IS that when I selected another sample, the player only plays this newly selected sample once and then returns to some "default" sample.. And that has nothing to do with the recording part (which isn't even being used at that time!)


#6

perhaps an issue with execution order? Could you share the patch?

table/load currently does its job inside the dsp loop, where it is likely to consume more time than available, causing buffer underruns, if there is sound playing that 'd cause repetition of the same audiobuffer... 3kHz tones.
Will be fixed in future...

@jaffasplaffa
position of table/record is only the start position.


#7

hmmm... this week is getting way too strange for me... I knew I feld sick and was a little foggy in my head, but I thought I could still get ideas straight and work things out the right way... I guess next time I just better stay quiet for a week....

so... ehm... I didn't have the former try-out anymore, so I just rebuild it a couple of minutes ago.. and it worked... (:unamused::expressionless::disappointed::disappointed_relieved::flushed::no_mouth:, one of these I guess... or all together...)
still though, I can't see what I've done differently from the last time.. for all I know, I just did the same right now like what I did back then... but then again.... you ain't "just having the flu"...


#8

so, well... with that "fixed" (without fixing somehow)..this means I can go straight ahead with my sampler :stuck_out_tongue:
The idea is to make a huge drum sample library with my modular synthesizer.
I've setup a 16 beat bar which plays a 36 note at the first step and note 38 at the 11th step from the arturia beatstep pro.
At the same time as note 36, the modular gets triggered (and makes a certain drumsound) and at the same time it triggers the recording of a sample. Next to this, it also triggers a counter, which goes into the string pre/suffix, to select a new samplename at each trigger.
At note 38, it triggers a "table/save" which saves the latest recorded sample to the selected prefix, index and suffix (prefix being BD, TM, SN, HH, OH, CY, PC, etc, suffix being .raw, index is the counter position).

So at first I set the prefix to the desired drumsound and then I just go at my modular (becoming quite a heavy beast lately) and route it to make endless variations of the selected drumsound (basskick, snare, hihats, cymbals etc)
From there it's just "hit play, sit back and wait for the magic to happen"

Whenever a sound is triggered, it's recorded and after the sound has died out, it gets saved to the SDcard automatically (depending on the desired length of the sound, I set a different BPM and sample length). Thanks to the modular being mostly analogue, even look-alike samples will always sound a bit different from each other.

Making samples between 32kb and 128kb... I guess I can make quite a sample library with a 32GB SDcard within a day.... :joy:


#9

as Johannes mentioned, this sounds like execution order... you probably didn't place things in exactly the same position as before, so slightly different behaviour.

if I look at you image above, you can see a couple places where perhaps execution order is not as you expect.

  • your 'Play Sample' control, is below both the wave/play and table/play so will be executed on the next k-rate cycle.
  • your wave/play is below the scope so will be evaluate on the next k-rate cycle.
  • table /record will be evaluated after the ctrl/toggle but before the logic/inv

in practice, on this simple patch easy to spot, and unlikely to make a difference (due to it mainly be using interaction) , but its good to get in the habit of avoiding this. yes the patch won't look as pretty or laid out as nicely, and take more space up.. if you do this regularly, you will find certain pattens in the way you lay things out.

my biggest tip though is quite simple, just look at the object headers and think about how these imply execution order, and this means lining up the tops of objects, and do NOT be tempted to one up inlets/outlets.
(generally you seem to be doing this, but the above example kind of break this pattern)

you probably know all this , already, but I though worth re-interating, as execution order is perhaps the easiest thing to get wrong, and hardest to fix ... and I still do it all the time :smile:


#10

@thetechnobear

I noticed if you push tab button on Mac Axoloti automatically selects the next parameter on an object.... And if last parameter of an objects is selected, pushing the tab button selects next objects first parameter....

Could the tab button be used as temprorary solution to check order of execution?


#11

I try to keep the order of execution right, but I also like to keep things a bit tidy.
As for some of the orders, I thought it wouldn't mind that much that I placed certain controls/object above others which would naturally come earlier in order, as long as there is enough time between the updating of the two.
eg. recording a sample and playing them was done by hand, so in-between those two were a couple of seconds... I thought that would be more then enough time to get updated, even if it were in the wrong order...


#12

soundcloud modular&axoloti
Trying out my new modular-synth drum-sample library (together with live modular drums) and glitch-effect (starts at comment).
One board left... what shall I do... will it be a polyphonic synthesizer... or a big midi-arpeggiator for my modular...? :stuck_out_tongue:


#13

yeah, as i said, was more general advice....

though id say this sentence is 'not quite' right. its really nothing to do with enough time, things are executed in strict sequence, synchronously, (with very few exceptions).

actually axoloti execution order is extremely simple... just look at object placement, but its very easy to let the wires mislead you... as its easy to think data flows down the wires, which it does not!