DSP Robotics Support

KG_is_back wrote: As for audio effects, I would like to keep it lightweight. Are there any specific ones that should be included? Perhaps a built in reverb?

I think that a reverb is the only absolutely essential effect because it can bring so much space to any sound. As long as it can be turned off it's a great way to audition presets. One can always use one's favourite reverb in the DAW for actual mixing in a song.

Chorus is good for synths but more limited for samplers. After all, if you want a choir sound you just use a choir sample!

Delay or repeat echo is nice to have for playing around especially for Dave Gilmour wannabes, as is saturation distortion for guitar samples.

Static filters for cabinet simulation and body resonance is nice too but the samples themselves can have that embedded.

In conclusion I would say to include whatever will show off the capabilities of the plugin and the included samples to create that wow factor. As long as the effects can be bypassed the user can always add what they want in the DAW project.

Cheers

Spogg

I've run into a terrible problem. The preset file does not save properly.

The data that should be saved is a hash. Elements in the hash are data provided from individual parts of the gsamp.

When the hash is marshalled and saved into a file it gets corrupted somehow, and when it gets read from a file and unmarshalled, nested arrays in the hash do not unmarshal properly. The error is definitely the file not saving/opening properly, because when I unmarshal the original data (the one that is marshalled and prepared to be saved to a file) it works just fine.

I really don't know what to do... Please if anyone has any ideas...

Please note, the schematic provided does not contain samples (otherwise it wouldn't fit the filesize limit), so it will not play any sound.

EDIT: I'm so retarded... I was not writing/reading the file as binary... problem solved by adding "b" in two places in the code

OK guys, new update is here...

Changes:
-saving preset file now works correctly
-added first midi effect - Strum simulator
-added "preview" button, which will play the selected sample (the selected region specifically) at original speed.

Since this version, I will try to keep preset file loading backward compatible, at least until version 1.0, where I will release preset-file converter if necessary.

Here is a preview preset including wavefiles. It's not very spectacular... Just my old electric guitar, with poor old strings. I actually have not played it at least a year. The preset should work best with some kind of ampsim behind it...
Eguitar.rar

Another problem I'd like to work on is the sample display. Currently the mem minmax prim is used to generate the envelope with a few thousand point resolution. Problem is, when you load a big file and zoom in, the resolution is insusficient. What I'd like to do is, to always have constant amount of points per window (so resolution increases with zoom)... Problem is, there is no prim which would led you extract only specific section of wave... Sorry if I'm not clear enough... my brain isn't working today...

i don't had a close look to your project, but maybe this could help,
here is a wavedisplay with zoom (and 100ms markers)..
i started this some years ago and never finished it so its far away from optimising but maybe the way i did the zoom and scroll could be of interest for you - i used the translate primitive to do the scrolling and zooming

Thanks Nubeat, but unfortunately your schematic does exactly what I wish to avoid. It converts the wave file to float array and then processes it in ruby. When I load a wave that is over a minute long, the ruby can't handle it.

I think I (or preferably someone else) will have to write a new mem-minmax prim which also takes start and end points as parameter, to recalculate only specific sections of the wave file... That means using mem to address prim and assembly, which almost certainly means crashes....

Hi KG

I love the new features!
The WAV preview is exactly what I wanted to see (and hear!). Also it’s nice to have a set of real samples to play around with, and the guitar sounds great.

I also very much like that you can have a multi-sample in one WAV file and choose which parts are used.

Regarding editing, I found it’s tricky to move to the exact attack start using the graphic editor. You say you want a zoom function and that would be nice but what about a simple sample step function, maybe with 2 speeds? You’d have a sample value readout or vertical graph, so just drag to the approximate start then shuttle backwards and forwards until you got the attack point you want. For more sophistication, rather than zoom the whole graph you could have a separate short window display graph showing several samples either side the current cursor position. Just some ideas.

Some points:

- The group names seem to be 1 octave out with respect to the WAV name, e.g. group says F3 but WAV is F4 (minor naming issue I suspect).

- When I move the start point for the attack more into each wave section, for all samples, and I play 1 octave down I still get the previous attack start point setting, not the one I just edited.

- There is a “latency” lag when playing the notes 1 octave lower than the WAV’s centre value. This may relate to the point above. This is present in the VSTi export too. It feels like about 100mS or so.

- When using the strum feature and repeating chords, I get timing issues with some of the notes; some sound late or out of order. Maybe a MIDI buffer needs to be cleared when notes are released and the buffer contents not passed to MIDI out…? This could allow part-chord strumming for more expression and variation.

As always, I hope my comments are seen as constructive and I’m well impressed with what you’ve achieved with this project so far. And thank you for sharing this work.

Cheers

Spogg

Thanks for the feedback Spogg.

Spogg wrote:Regarding editing, I found it’s tricky to move to the exact attack start using the graphic editor.

You might be happy to hear that the lines automatically snap to zero crossings.

Spogg wrote:For more sophistication, rather than zoom the whole graph you could have a separate short window display graph showing several samples either side the current cursor position

That's a great idea! I will have to think about where to put it. I don't what the gui to be too big. I was considering moving the sample editor to different tab.

Spogg wrote:- The group names seem to be 1 octave out with respect to the WAV name, e.g. group says F3 but WAV is F4 (minor naming issue I suspect).

Yes, a minor naming issue. I've put the note numbers one too heigh when recording them and when I noticed it, I was lazy to rename all 20wavs...

Spogg wrote:- When I move the start point for the attack more into each wave section, for all samples, and I play 1 octave down I still get the previous attack start point setting, not the one I just edited.

- There is a “latency” lag when playing the notes 1 octave lower than the WAV’s centre value. This may relate to the point above. This is present in the VSTi export too. It feels like about 100mS or so.

that might be because of the pitch shifting method. The sampler uses simple re-sampling to change pitch, which means, when note is played one octave lower, it is played back at 0.5x speed. This might over-emphase any lag from imprecise start-point.

As for why you get previous attack setting, that might be, because the lookup tables for the audio-part of the sampler update only after you release the mouse key - the line following your mouse while dragging is purely visual. This is so, because the lookup tables are rather large and must be recalculated for all samples of all groups at the same time. Having them updating, while dragging could cause freezing issues with big presets.

Spogg wrote:- When using the strum feature and repeating chords, I get timing issues with some of the notes; some sound late or out of order. Maybe a MIDI buffer needs to be cleared when notes are released and the buffer contents not passed to MIDI out…? This could allow part-chord strumming for more expression and variation.

The strum simulator plays the first note that arrives first, and then accumulates all notes that come shortly after, sorts them by pitch and plays them in desired order. I've made it that way, because otherwise there would have to be short latency in the midi. All you have to do to make the strums have natural order is to make sure you hit the lowest/highest note first.

Spogg wrote:As always, I hope my comments are seen as constructive and I’m well impressed with what you’ve achieved with this project so far. And thank you for sharing this work.

I thank you Spogg for your feedback. It helps me to focus my short attention-span on actually finishing this project. This is actually my at least 3rd attempt to make this kind of multisampler and in fact, even this one already survived one crisis. What I've found, it makes the job easier and more enjoyable to set smaller milestones, that I can look forward to finishing and have someone to bounce ideas out of during the process and share the little victories with. All comments are highly appreciated and so far they've been very helpful!

KG_is_back wrote:Thanks Nubeat, but unfortunately your schematic does exactly what I wish to avoid. It converts the wave file to float array and then processes it in ruby. When I load a wave that is over a minute long, the ruby can't handle it.

I think I (or preferably someone else) will have to write a new mem-minmax prim which also takes start and end points as parameter, to recalculate only specific sections of the wave file... That means using mem to address prim and assembly, which almost certainly means crashes....

I doubt that Ruby is the cause. I rather think that the high amount of data in combination with the prim needing to convert it to an array (and again converting to a Ruby array) is the cause. What you'd need is a method/technique to fill the array over time and only access it after everything is prepared. I currently have no idea, how. But as soon as you solved this, you should definitely go the Ruby path.
For the display, speed is more important than accuracy. Start with the graphic frame's width. If you draw to a 400 pixel width, you probably only need like 100 sample points, connected through simple lines. The rest is simple math:
If zoom == 100% then the step size equals array-size divided by 100, as integer.
If zoom == 50% then the step size is (array-size * 0.5) divided by 100, as integer.
Etc.
The step size tells you which samples to grab from the source (don't forget the offset when zoomed in, but I don't want to make it too complicated here).
array[stepsize * currentrendersamplepoint)
where currentrendersamplepoint is from 0 to 99 in this example.

EDIT: While re-reading what I wrote, I think the zoom part may be misleading for the values I used. zoom = 50% does mean you're zooming in, the part displayed in the window is now double as precise, because it displays a smaller range. In Photoshop this would be called zoom = 200%, but I wanted to make sure you understand the relation between zoom and array-size factor. If you want to work with zoom values as you know them from apps like Photoshop then it would be zoom == 200%, array-size * (1/2), or generalized:
zoom [1 = 100%], stepsize = array-size * (1 / zoom)

As for why you get previous attack setting, that might be, because the lookup tables for the audio-part of the sampler update only after you release the mouse key - the line following your mouse while dragging is purely visual. This is so, because the lookup tables are rather large and must be recalculated for all samples of all groups at the same time. Having them updating, while dragging could cause freezing issues with big presets.

Hi KG
I rechecked this and it's not mouse-up related. I've made the preset attached which just addresses the G4 (=G3) wav to demo the issue. If you play the G3 note (G below middle C, note no. 55) you will hear my new edited late start position for each note. If you then play G2, 1 octave down, you still hear the whole note.
I'm really puzzled by this but I don't know the schematic's functioning so well, so I can't tell you what's going on. It's just not what I would expect to happen.

Cheers

Spogg

Hi KG

You may have planned this already but I have a feature request/suggestion.

It would be nice to have a pitched/un-pitched option for any group. By un-pitched I mean just playing at the default native speed of the samples and not influenced by the key number.

Why? This would give some extra flexibility for some situations. For example, let’s say I want a pitched drum sound across a range of keys. I want the skin and body sound to vary but I want the strike sound (stick, pedal…) to be fixed in pitch. Or maybe a vocal sound where the plosive is fixed but the pitch varies. That sort of thing.

I think this should be fairly easy to implement and I did this for my Q-50 synth although the sample playing was much less sophisticated.

Cheers

Spogg