# AudioBuffer to MemoryBlock

**URL:** <https://forum.juce.com/t/audiobuffer-to-memoryblock/22422>\
**Category:** Audio Plugins\
**Created:** [May 15, 2017, 3:12am UTC](https://forum.juce.com/t/audiobuffer-to-memoryblock/22422 "2017-05-15T03:12:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jasperswami](https://avatars.discourse-cdn.com/v4/letter/j/839c29/32.png) [@jasperswami](https://forum.juce.com/u/jasperswami)\
**Post date:** [May 15, 2017, 3:12am UTC](https://forum.juce.com/t/audiobuffer-to-memoryblock/22422/1 "2017-05-15T03:12:03Z")

</div>

Hey, apologies if this is a totally dumb/noob question, but is there a direct way to store audiobuffer data to a memory block? I was wanting to use toBase64Encoding on the block to save the audio data into the xml element as an attribute and then somehow read it back into my audiobuffer when the plugin state loads.

---

<div class="post-metadata">

**Author:** ![jasperswami](https://avatars.discourse-cdn.com/v4/letter/j/839c29/32.png) [@jasperswami](https://forum.juce.com/u/jasperswami)\
**Post date:** [May 15, 2017, 3:11pm UTC](https://forum.juce.com/t/audiobuffer-to-memoryblock/22422/2 "2017-05-15T15:11:16Z")

</div>

I’ll also add that I tried to just add the buffer to the block with something like

```
MemoryBlock loadedaudio;
	    loadedaudio.append(fileBuffer, sizeof(fileBuffer.getSample(0,0)) * fileBuffer.getNumSamples()* fileBuffer.getNumChannels());

```

But clearly this does not work because the input of the first argument has to be in the form of const void \*, which the audioBuffer call fileBuffer is not. Is there a way to make that conversion? Perhaps I’m going about this all wrong to begin with?

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [May 15, 2017, 4:40pm UTC](https://forum.juce.com/t/audiobuffer-to-memoryblock/22422/3 "2017-05-15T16:40:05Z")

</div>

> [@jasperswami](#):
>
> is there a direct way to store audiobuffer data to a memory block?

Sure, just use a MemoryOutputStream in the [AudioFormat::createWriterFor (OutputStream\*, …)](https://juce.com/doc/classAudioFormat#ae93a8144520e5bd2902a5daa97cc443b)…

> [@jasperswami](#):
>
> I was wanting to use toBase64Encoding on the block to save the audio data into the xml element as an attribute and then somehow read it back into my audiobuffer when the plugin state loads.

I don’t know, if that’s a great idea. I would rather append the audio file to the xml file and use a [SubregionStream](https://juce.com/doc/classSubregionStream) to read it back. In the xml you can save the size of the xml as header. Allow some padding, because the numbers in the xml could change the header size by a few bytes.

HTH

---

<div class="post-metadata">

**Author:** ![jasperswami](https://avatars.discourse-cdn.com/v4/letter/j/839c29/32.png) [@jasperswami](https://forum.juce.com/u/jasperswami)\
**Post date:** [May 15, 2017, 9:27pm UTC](https://forum.juce.com/t/audiobuffer-to-memoryblock/22422/4 "2017-05-15T21:27:21Z")

</div>

Hey daniel, thanks for the insight! I’ll give this a try. I’ll also mention for anybody else that finds any of this useful, I mainly wanted a way for the plugin to remember what audio file I had opened with file chooser. Since I’m using AudioProcessorValueTreeState for my plugin parameters, In the interim I decided to just save out the full file path in the ValueTree state of the processor whenever I open an audio file:

`parameters.state.setProperty("pathname",file.getFullPathName(),nullptr);`

save out the parameters in getStateInformation

```
void AudioProcessor::getStateInformation (MemoryBlock& destData)
{
	ScopedPointer<XmlElement> xml (parameters.state.createXml());
	copyXmlToBinary (*xml, destData);
}

```

and then reload the file with that path in the setStateInformation function. It seems to be working well. Obviously there’s the pitfall of it not finding the audio data if I move audio files around on my computer, etc. But I suppose it’s another option for anybody wanting to reload the original audio data, and not AudioBuffer data that’s already been through some processing by the plugin?