next »

[elimmedia]

I have a question regarding BASS_MIDI.


MIDI_EVENT_TEMPO, which is global event won't be affected if it is set using "BASS_MIDI_StreamEvent" before play.

Any other way to set tempo before play midi?

thank you in advance

[Ian @ un4seen]

The problem you are encountering there is that the MIDI file may have its own TEMPO events, which will override your tempo setting. The overcome that, you need re-override the file's TEMPO events, which can be done via a BASS_SYNC_MIDI_EVENT sync. Something like this...

BASSMIDI.BASS_MIDI_StreamEvent(handle, 0, BASSMIDI.MIDI_EVENT_TEMPO, yourtempo); // apply your tempo setting
BASS.BASS_ChannelSetSync(handle, BASSMIDI.BASS_SYNC_MIDI_EVENT|BASS.BASS_SYNC_MIXTIME, BASSMIDI.MIDI_EVENT_TEMPO, TempoSync, 0); // and set a sync to override TEMPO events

BASS.SYNCPROC TempoSync=new BASS.SYNCPROC() {
public void SYNCPROC(int handle, int channel, int data, Object user) {
BASSMIDI.BASS_MIDI_StreamEvent(channel, 0, BASSMIDI.MIDI_EVENT_TEMPO, yourtempo); // apply your tempo setting
}
};

Please see the MIDITEST example for a more complete example of adjusting the tempo.

[BassPassion]

Now that Android supports Intel in the Emulator¹, (which is a awesome performance improvement during development) and devices are starting to pop up using Intel chipsets (like Lenovo K800²) are there any plans of compiling an Intel version of Bass for Android?


¹http://developer.android.com/tools/devices/emulator.html
²http://www.techradar.com/news/phone-and-communications/mobile-phones/hands-on-lenovo-k800-review-1053719

[Ian @ un4seen]

There is an x86 Android version of BASS that is currently available separately on request. I guess it will soon have to be added to the main package

[elimmedia]

that makes sense!

Thank you Ian!

The problem you are encountering there is that the MIDI file may have its own TEMPO events, which will override your tempo setting. The overcome that, you need re-override the file's TEMPO events, which can be done via a BASS_SYNC_MIDI_EVENT sync. Something like this...

BASSMIDI.BASS_MIDI_StreamEvent(handle, 0, BASSMIDI.MIDI_EVENT_TEMPO, yourtempo); // apply your tempo setting
BASS.BASS_ChannelSetSync(handle, BASSMIDI.BASS_SYNC_MIDI_EVENT|BASS.BASS_SYNC_MIXTIME, BASSMIDI.MIDI_EVENT_TEMPO, TempoSync, 0); // and set a sync to override TEMPO events

BASS.SYNCPROC TempoSync=new BASS.SYNCPROC() {
public void SYNCPROC(int handle, int channel, int data, Object user) {
BASSMIDI.BASS_MIDI_StreamEvent(channel, 0, BASSMIDI.MIDI_EVENT_TEMPO, yourtempo); // apply your tempo setting
}
};

Please see the MIDITEST example for a more complete example of adjusting the tempo.

[elimmedia]

Hello Ian,

I have a question regarding BASS_MIDI again

We have made sound font and apply into BASS.

It seems that exclusive class does not properly work on BASS.

For example, we have drumset and hi-hat need to be stereo.

we set two closed hi-hat on a same key with different pan for stereo and set the exclusive class 4 (both same)
we also set opened hi-hat(mono) with the same class 4 (different key)

What we were expecting is when closed hi-hat pressed, previous opened hi-hat need to be stopped.

Using this sound font, it works fine on general MIDI player, but BASS can sound only one side of closed hi-hat.

Please let us know if you have any idea for this.

Thank you in advance.

- Shin

[Ian @ un4seen]

Please upload your soundfont to investigate what's happening here...

   ftp.un4seen.com/incoming/

[elimmedia - shin]

I will make sound font shortly and send it to you. The one I send you has only drum set.

Beside the issue, I have another question for you.

I am curious if there is a way to protect custom soundfont.

ex.
1. encrypt a soundfont using MD5 and decrypt it when it is loaded.
2. custom soundfont has special header and check it on load.

Please upload your soundfont to investigate what's happening here...

   ftp.un4seen.com/incoming/

[elimmedia-shin]

we actually found the solution regarding exclusive class.

we set exc class on only one side of closed hi-hat and it works.

We anyway sent you the soundfont file for you.

Thank you.

Please upload your soundfont to investigate what's happening here...

   ftp.un4seen.com/incoming/

[rai2270]

Hi,
When I use proguard to obfuscate my code, I've found out that my app will crash if Bass is in the project (and in use during runtime). When I remove Bass from the code (only Bass) and obfuscate again, all is OK.
I've tried to make it Bass will not be inside proguard, but it did not help.
Anyone got this problem?

[rai2270]

Well, to answer my own question:

put this in proguard.cfg:

-keep class com.un4seen.bass.** {
  public protected private *;
}

[Ian @ un4seen]

I am curious if there is a way to protect custom soundfont.

ex.
1. encrypt a soundfont using MD5 and decrypt it when it is loaded.
2. custom soundfont has special header and check it on load.

I think that should be possible using the undocumented option of loading a soundfont from memory, ie. you could decrypt your soundfont to memory and then pass that to BASSMIDI. The BASSMIDI Java class didn't include support for that feature, but I have put an update up in the 1st post which should do. You would decrypt your soundfont to a ByteBuffer and then pass that to BASS_MIDI_FontInit along with the BASS_MIDI_FONT_MEM flag. Let me know if you have any trouble with it.

Thanks for the test soundfont. I'll check if BASSMIDI is currently doing anything wrong with it.

[elimmedia-shin]

Thank you for your quick update!

I have tested the new font load feature.

It loads up soundfont successfully, but sounds like crashed instruments.

I am also afraid if it is ok to allocate bytebuffer with huge size like 140MB.

We've used sampling chip which has 32MB capacity, but since we decided to use BASS MIDI and soundfont, we will make much better samplings.

The soundfont we've created is 25MB.

Below is the code for loading soundfont.

          private boolean initFont(String file){
      if(mSoundFont != 0)return true;
      ByteBuffer bb = null;
      try{
         File tempFile = new File(file);
         FileInputStream f = new FileInputStream( file );
         FileChannel ch = f.getChannel( );
         bb = ByteBuffer.allocate( (int)ch.size() );
         int read = 0;
         read = ch.read(bb);
         System.out.println("==== read check : "+tempFile.length() + " , " + read);
      }catch(Exception e){
         System.out.println("========= exception on load font : " + e);
         return false;
      }
      int newfont=BASSMIDI.BASS_MIDI_FontInit(bb, BASSMIDI.BASS_MIDI_FONT_MEM);
      if (newfont==0) {
         return false;
      } else {
         BASSMIDI.BASS_MIDI_FONT[] sf={new BASSMIDI.BASS_MIDI_FONT()};
         sf[0].font=newfont;
         sf[0].preset=-1; // use all presets
         sf[0].bank=0; // use default bank(s)
         BASSMIDI.BASS_MIDI_StreamSetFonts(0, sf, 1); // set default soundfont
         BASSMIDI.BASS_MIDI_StreamSetFonts(mHandle, sf, 1); // set for current stream too
         BASSMIDI.BASS_MIDI_FontFree(mSoundFont); // free old soundfont
         mSoundFont=newfont;
         return true;
      }
   }

I am curious if there is a way to protect custom soundfont.

ex.
1. encrypt a soundfont using MD5 and decrypt it when it is loaded.
2. custom soundfont has special header and check it on load.

I think that should be possible using the undocumented option of loading a soundfont from memory, ie. you could decrypt your soundfont to memory and then pass that to BASSMIDI. The BASSMIDI Java class didn't include support for that feature, but I have put an update up in the 1st post which should do. You would decrypt your soundfont to a ByteBuffer and then pass that to BASS_MIDI_FontInit along with the BASS_MIDI_FONT_MEM flag. Let me know if you have any trouble with it.

Thanks for the test soundfont. I'll check if BASSMIDI is currently doing anything wrong with it.

[Ian @ un4seen]

I have tested the new font load feature.

It loads up soundfont successfully, but sounds like crashed instruments.

One possibility is that your ByteBuffer might be garbage collected, as it is local to the "initFont" function and BASS_MIDI_FontInit isn't currently incrementing its reference count. I'll make BASS_MIDI_FontInit increment the reference count in the next update, but to confirm whether that is the issue, please try moving the "bb" declaration outside of the function.

By the way, I think using "ByteBuffer.allocateDirect" instead of "ByteBuffer.allocate" will give better performance in reading the file to memory and BASSMIDI accessing it.

I am also afraid if it is ok to allocate bytebuffer with huge size like 140MB.

I guess that could be a problem. I think "Runtime.maxMemory" will tell how much memory is available to your process, but it is apparently possible to get around the limit by allocating memory in native code. If you happen to already be implementing some things in native code, you could try allocating the soundfont's memory there too. Implementing the decryption in native code would probably be a good idea too (faster than doing it in Java).

If you only need the soundfont's sample data to be encrypted, then another (more complex) option is to create a BASS add-on to decrypt the data.

[elimmedia-shin]

I moved ByteBuffer declaration outside of the function, and it reduces the chance of crashed sound, but still produces the problem.

We just want our soundfont protected and plug-in option sounds good to us.

I had a chance to make some helloworld for JNI, but I am not a C coder.

If you give us a guideline or sample code for BASS plug-in, it would be much easier for me to try

I have tested the new font load feature.

It loads up soundfont successfully, but sounds like crashed instruments.

One possibility is that your ByteBuffer might be garbage collected, as it is local to the "initFont" function and BASS_MIDI_FontInit isn't currently incrementing its reference count. I'll make BASS_MIDI_FontInit increment the reference count in the next update, but to confirm whether that is the issue, please try moving the "bb" declaration outside of the function.

By the way, I think using "ByteBuffer.allocateDirect" instead of "ByteBuffer.allocate" will give better performance in reading the file to memory and BASSMIDI accessing it.

I am also afraid if it is ok to allocate bytebuffer with huge size like 140MB.

I guess that could be a problem. I think "Runtime.maxMemory" will tell how much memory is available to your process, but it is apparently possible to get around the limit by allocating memory in native code. If you happen to already be implementing some things in native code, you could try allocating the soundfont's memory there too. Implementing the decryption in native code would probably be a good idea too (faster than doing it in Java).

If you only need the soundfont's sample data to be encrypted, then another (more complex) option is to create a BASS add-on to decrypt the data.

[fulbert]

Does BASS_ChannelSetSync with BASS_SYNC_META work for STREAMPROC_PUSH?

Seems to work for BASS_StreamCreateURL but if I use BASS_StreamCreate, SYNCPROC callback does not trigger.

[Ian @ un4seen]

I moved ByteBuffer declaration outside of the function, and it reduces the chance of crashed sound, but still produces the problem.

A BASSMIDI update is up in the 1st post, in which BASS_MIDI_FontInit will increment the ByteBuffer's reference count (to prevent it being garbage collected before BASS_MIDI_FontFree is called). So you could give that a try and see if the problem still happens. If it does, does the problem not happen if you pass the soundfont's filename directly to BASS_MIDI_FontInit instead? If the problem is only happening with a particular soundfont, please upload that to have a look at.

The update also includes a fix for the exclusive class issue that you had with your soundfont.

We just want our soundfont protected and plug-in option sounds good to us.

I had a chance to make some helloworld for JNI, but I am not a C coder.

If you give us a guideline or sample code for BASS plug-in, it would be much easier for me to try

The example BASS add-on code hasn't been updated for Android yet, but I'll get that updated and sent your way, hopefully by early next week. What language is your decryption code written in? Note an add-on will need to be written in C/C++.

Does BASS_ChannelSetSync with BASS_SYNC_META work for STREAMPROC_PUSH?

Seems to work for BASS_StreamCreateURL but if I use BASS_StreamCreate, SYNCPROC callback does not trigger.

No. BASS_SYNC_META syncs are triggered when metadata is received from Shoutcast servers, so they don't apply to custom streams (there is no metadata).

[elimmedia-shin]

decryption code will be written in C/C++.

I really appreciate your quick response.

I moved ByteBuffer declaration outside of the function, and it reduces the chance of crashed sound, but still produces the problem.

A BASSMIDI update is up in the 1st post, in which BASS_MIDI_FontInit will increment the ByteBuffer's reference count (to prevent it being garbage collected before BASS_MIDI_FontFree is called). So you could give that a try and see if the problem still happens. If it does, does the problem not happen if you pass the soundfont's filename directly to BASS_MIDI_FontInit instead? If the problem is only happening with a particular soundfont, please upload that to have a look at.

The update also includes a fix for the exclusive class issue that you had with your soundfont.

We just want our soundfont protected and plug-in option sounds good to us.

I had a chance to make some helloworld for JNI, but I am not a C coder.

If you give us a guideline or sample code for BASS plug-in, it would be much easier for me to try

The example BASS add-on code hasn't been updated for Android yet, but I'll get that updated and sent your way, hopefully by early next week. What language is your decryption code written in? Note an add-on will need to be written in C/C++.

Does BASS_ChannelSetSync with BASS_SYNC_META work for STREAMPROC_PUSH?

Seems to work for BASS_StreamCreateURL but if I use BASS_StreamCreate, SYNCPROC callback does not trigger.

No. BASS_SYNC_META syncs are triggered when metadata is received from Shoutcast servers, so they don't apply to custom streams (there is no metadata).

[elimmedia]

I have tested the new update and it has the same problem.

I also tried passing filename directly and has same problem too.

I moved back to old library just in case, and it sounds fine.

I moved ByteBuffer declaration outside of the function, and it reduces the chance of crashed sound, but still produces the problem.

A BASSMIDI update is up in the 1st post, in which BASS_MIDI_FontInit will increment the ByteBuffer's reference count (to prevent it being garbage collected before BASS_MIDI_FontFree is called). So you could give that a try and see if the problem still happens. If it does, does the problem not happen if you pass the soundfont's filename directly to BASS_MIDI_FontInit instead? If the problem is only happening with a particular soundfont, please upload that to have a look at.

The update also includes a fix for the exclusive class issue that you had with your soundfont.

We just want our soundfont protected and plug-in option sounds good to us.

I had a chance to make some helloworld for JNI, but I am not a C coder.

If you give us a guideline or sample code for BASS plug-in, it would be much easier for me to try

The example BASS add-on code hasn't been updated for Android yet, but I'll get that updated and sent your way, hopefully by early next week. What language is your decryption code written in? Note an add-on will need to be written in C/C++.

Does BASS_ChannelSetSync with BASS_SYNC_META work for STREAMPROC_PUSH?

Seems to work for BASS_StreamCreateURL but if I use BASS_StreamCreate, SYNCPROC callback does not trigger.

No. BASS_SYNC_META syncs are triggered when metadata is received from Shoutcast servers, so they don't apply to custom streams (there is no metadata).

[Ian @ un4seen]

I have tested the new update and it has the same problem.

I also tried passing filename directly and has same problem too.

I moved back to old library just in case, and it sounds fine.

OK. That looks like it is a more general problem then, not related to loading from memory. There were some internal tweaks recently (more floating-point calculations changed to fixed-point), so the problem is probably somewhere in that stuff. To locate the problem, please upload your soundfont and a MIDI file to reproduce it with here...

   ftp.un4seen.com/incoming/